Is this regular expression the specification of the format, or just an example? Because it does not handle the full range of possibilities here. What about

__pyproject__ = """\
    [project]
    ...
"""

While the backslash isn't necessary here, I regularly use multi-line strings in a context where a leading newline would be an error, so I tend to add the backslash without thinking. So I'd be surprised to find that a spec that says "a multi-line double-quoted string containing a valid TOML document" disallows this possibility.

There's also the possibility of people using doubled backslashes to include a backslash in the TOML.

This is fundamentally the issue with "use Python notation". Are you using Python, or are you using some subset? If the latter, then you need to define it explicitly, or someone will insist that the standard says you must support some obscure facet of Python syntax that you didn't even consider.

Probably, I should have posted what I wrote in the discourse thread directly here.

The following are other examples (non-exhaustive) of syntaxes that (to my understanding, and I might be wrong) seem to be permitted by the current state of the draft, are valid Python code, result in a string value (after Python's syntax interpretation) that is valid TOML, but might break the reference implementation:

__pyproject__ = """
[project]
readme.text = \"""
Hello, this is my awesome single-file utility script.
Try running::

    pipx run myfile.py
\"""
dependencies = ['tomli; python_version < "3.11"']
"""

__pyproject__ = """
project.dependencies = """ """\
['tomli; python_version < "3.11"']
"""

__pyproject__ = (
   """
   project.dependencies = ['tomli; python_version < "3.11"']
   """
)  # Auto-formatters sometimes add parenthesis...

...

This is related to the previous comment.
The parsing problems might be addressed by restricting the allowed syntax¹ or improving the reference implementation to be "more Python-aware".

I added:

In circumstances where there is a discrepancy between the regular expression and the text specification, the text specification takes precedence.

Thanks, but in which case the text specification isn't clear enough (IMO) to write a parser for it. Note that I'm thinking about this from the perspective of potentially having to implement this for pipx, not as the author of a competing PEP.

And to be clear, if the PEP says that there is the potential for a discrepancy between the suggested regex and the formal spec, I'd personally avoid using the regex, because I prefer correctness over convenience. So this is a real issue for me.