TOML 1.1

@hukkin

Feature 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

See also hukkin/tomli#273 for tomli.

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]:

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

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 nothing

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.

FYI, I've created a DPO thread on how this affecting packaging tools (like pip): https://discuss.python.org/t/adopting-toml-1-1/105624

tomli 2.4.0 has been released with TOML 1.1.0 support 🚀

Who would like to work on the CPython PR?

@encukou

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?

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

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.)

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.

Yeah, throw those it as well.

(I think Petr means include these changes in the one PR adding 1.1 support — CPython doesn’t generally do style-only PRs)

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.

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 :)

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?

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.

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.

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.

gh-142956: Update `tomllib` to parse TOML 1.1.0 (#144243)

Merged. Thank you!

pythongh-142956: Update `tomllib` to parse TOML 1.1.0 (python#144243)

Navigation Menu

Repository navigation

TOML 1.1 #142956

Feature or enhancement

Proposal:

Has this already been discussed elsewhere?

Links to previous discussion of this feature:

Linked PRs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

TOML 1.1 #142956

Description

Feature or enhancement

Proposal:

Has this already been discussed elsewhere?

Links to previous discussion of this feature:

Linked PRs

Activity

hugovk commented on Dec 18, 2025

chirizxc commented on Dec 20, 2025

AA-Turner commented on Dec 20, 2025

chirizxc commented on Dec 20, 2025

hukkin commented on Dec 20, 2025

notatallshaw commented on Jan 9, 2026

hugovk commented on Jan 11, 2026

hukkin commented on Jan 11, 2026

hugovk commented on Jan 11, 2026

encukou commented on Jan 12, 2026

hukkin commented on Jan 12, 2026

encukou commented on Jan 12, 2026

merwok commented on Jan 12, 2026

notatallshaw commented on Jan 12, 2026

hugovk commented on Jan 13, 2026

notatallshaw commented on Jan 21, 2026

hauntsaninja commented on Jan 21, 2026

BrenBarn commented on Jan 21, 2026

encukou commented on Jan 22, 2026

encukou commented on Feb 3, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions