GeezerVison is showing github.com — TOML 1.1 · Issue #142956 · python/cpython
DescriptionFeature or enhancement
Proposal:
A new version of the TOML spec has been released: https://toml.io/en/v1.1.0
xref #123905 from last year
cc @hukkin @hauntsaninja
A
Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
No response
Linked PRs
Reacted by Shunichiro Nomura, Bartosz Sławecki, chrysn, Taneli Hukkinen, quazgar, Edgar Ramírez Mondragón, Marek Madejski and Fosox Activityhugovk commented on Dec 18, 2025 Reacted by Adam Turner and Bartosz Sławecki chirizxc commented on Dec 20, 2025 Will both versions of TOML be supported simultaneously?
Something like:
def loads(
s: str,
/,
*,
parse_float: Callable[[str], Any] = float,
toml_version: Literal["1.0.0", "1.1.0"] = "1.0.0",
) -> dict[str, Any]:AA-Turner commented on Dec 20, 2025 There aren't any incompatible changes in the spec, as far as I'm aware. What would be the use-case for using an older spec version?
A chirizxc commented on Dec 20, 2025
There aren't any incompatible changes in the spec, as far as I'm aware. What would be the use-case for using an older spec version?
A
For example, if the input is TOML v1.0.0 and you want an error to occur when it does not comply with it:
from pprint import pprint
import toml_rs
input_toml = """\
tbl = {
key = "a string",
moar-tbl = {
key = 1,
},
}
"""
pprint(toml_rs.loads(input_toml, toml_version="1.0.0"))
# toml_rs.TOMLDecodeError: TOML parse error at line 1, column 8
# |
# 1 | tbl = {
# | ^
# newlines are unsupported in inline tables, expected nothinghukkin commented on Dec 20, 2025 Users can e.g. install an old TOML 1.0.0 compatible version of Tomli if they need the parser to error on new TOML 1.1.0 only syntax. But I don't see much of a real world use case here.
Maintaining TOML 1.0.0 support would be more relevant if tomllib had write capability and we were adding write support for the new syntax, as that'd make older parsers and tomllibs of older Python versions error. Luckily Python doesn't include write support so it's not something we need to consider. Reacted by Adam Turner, Stan Ulbrych, MrSnapperVibes, Lukas Atkinson and Petr Viktorin notatallshaw commented on Jan 9, 2026 hugovk commented on Jan 11, 2026 tomli 2.4.0 has been released with TOML 1.1.0 support 🚀
Who would like to work on the CPython PR? hukkin commented on Jan 11, 2026
Who would like to work on the CPython PR?
Should I, since the work in Tomli repository is by me? I'm not a lawyer though, so can't tell for sure if there's a problem with someone else down-/upstreaming (not sure which one it is here 😄) the work?
Do codeowners @encukou and @hauntsaninja want this as a single TOML v1.1 PR or split into four by features like it was done in Tomli?
There's still almost four months before Python 3.15 merge window closes, so perhaps it makes sense to wait a couple weeks or a month waiting for potential Tomli v2.4.0 bug reports? hugovk commented on Jan 11, 2026
Who would like to work on the CPython PR?
Should I, since the work in Tomli repository is by me? I'm not a lawyer though, so can't tell for sure if there's a problem with someone else down-/upstreaming (not sure which one it is here 😄) the work?
Go for it!
If anyone else was involved in the Tomli PRs, you can credit them with a Co-authored-by trailer:
https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors
Do codeowners @encukou and @hauntsaninja want this as a single TOML v1.1 PR or split into four by features like it was done in Tomli?
(Not a codeowner but) a single PR would be best.
There's still almost four months before Python 3.15 merge window closes, so perhaps it makes sense to wait a couple weeks or a month waiting for potential Tomli v2.4.0 bug reports?
The next 3.15 alpha 4 is this Tuesday, I'm fine with it going in there if ready in time, to help get more exposure and early feedback. Otherwise, alpha 5 is 10th Feb. https://peps.python.org/pep-0790/#release-schedule encukou commented on Jan 12, 2026 A single PR is fine.
Users can e.g. install an old TOML 1.0.0 compatible version of Tomli if they need the parser to error on new TOML 1.1.0 only syntax. But I don't see much of a real world use case here.
Are you OK with maintaining the old version? That is: releasing tomli 2.3.1 if some serious bug needs to be fixed? (The code for the fix will need to be written anyway, until 3.14 is EOL.) hukkin commented on Jan 12, 2026
Are you OK with maintaining the old version? That is: releasing tomli 2.3.1 if some serious bug needs to be fixed? (The code for the fix will need to be written anyway, until 3.14 is EOL.)
Yes, I can do that.
Another question: is a PR welcome that does functionally nothing, but reduces the diff between tomllib and tomli? What I mean is changes such as
There's probably some more too. encukou commented on Jan 12, 2026 Yeah, throw those it as well. merwok commented on Jan 12, 2026 (I think Petr means include these changes in the one PR adding 1.1 support — CPython doesn’t generally do style-only PRs) Reacted by Petr Viktorin and Taneli Hukkinen notatallshaw commented on Jan 12, 2026 Hi, I'm a pip maintainer, and the discussion I raised in on DPO (https://discuss.python.org/t/adopting-toml-1-1/105624) has someone got away from me and gone in a direction I didn't expect.
Can we please hold off on merging TOML 1.1 into the stdlib until we have had more time to discuss the compatibility implications. At least not so soon as this Tuesday. Reacted by Taneli Hukkinen hugovk commented on Jan 13, 2026 Sure, I've started the 3.14.0a4 release, and we don't yet have the 1.1 PR up, so definitely no chance of it being in this one :) notatallshaw commented on Jan 21, 2026
Can we please hold off on merging TOML 1.1 into the stdlib until we have had more time to discuss the compatibility implications. At least not so soon as this Tuesday.
I withdraw my request to hold, while there are many open questions it appears clear now that no specific version of TOML is mandated by the specifications, further work needs to be done to coordinate tools and/or update specifications.
One question the Python packaging community has, is given the wording of PEP 680:
treat minor revisions as bug fixes
Is the intent to backport this to Python 3.14 and 3.13? hauntsaninja commented on Jan 21, 2026 We should not backport TOML 1.1 to Python 3.14 and 3.13
I was the author of that sentence. IIRC at the time it seemed possible that TOML 1.1 would be minor spec clarifications or would maybe ship while Python 3.11 was in a post feature stage (e.g. release candidate), so I wanted to keep the option open. Multi-line inline tables is a big enough and useful enough feature that I think backporting to 3.14 and 3.13 would be a bad idea. Reacted by Damian Shaw and Petr Viktorin BrenBarn commented on Jan 21, 2026
I withdraw my request to hold, while there are many open questions it appears clear now that no specific version of TOML is mandated by the specifications, further work needs to be done to coordinate tools and/or update specifications.
In my view this is an even stronger reason to hold. encukou commented on Jan 22, 2026 I don't think keeping tomllib at TOML 1.0 is on the table.
There might be a request to add a version argument or similar, but that would come on top of this PR. Reacted by Hugo van Kemenade and Shantanu encukou commented on Feb 3, 2026 Reacted by Hugo van Kemenade
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|