I think I agree with you, but it's worth noting that embedding TOML into a here-string also raises some problems: it means that a maximally correct parser will need to handle string continuations, for example. It's also incompatible with what existing tools do, which is consume an unspecified form of PEP 722's syntax. These are not insurmountable problems, but they are reasonable considerations.
[1]: https://discuss.python.org/t/pep-722-dependency-specificatio...
[2]: https://discuss.python.org/t/pep-723-embedding-pyproject-tom...
Not sure, however, that I buy the argument that it's going to be simpler for non-programmers to use TOML embedded inside a multiline string versus using something along the lines of requirements.txt - there's going to be absolutely zero syntax highlighting so things like missing quotes or bracket's will need to be carefully identified.
There's also going to be inevitable differences between `__pyproject__` and `pyproject.toml` which could lead to more confusion, such as the `readme` key - that's likely to be useful to include some help information alongside your script so it's self documenting, but in `pyproject.toml` it must refer to another file and in `__pyproject__` I'd assume it can itself be a multiline string..?
I understand their reasoning to be that it would require other tools to know how to parse python. Which is much more difficult than parsing toml
On that note, I will never understand why they chose .toml instead of just json or yaml..
JSON - not the most convenient to use for human beings, too much quoting, not too git friendly because of disallowed trailing commas, etc.
TOML sits somewhere inbetween, easy to write but the spec is very short; also being used in Rust and a few other places.
Instead of:
[project] requires-python = ">=3.11" dependencies = [ "requests<3", "rich", ]
You could write:
{ "project": { "requires-python":">=3.11", "dependencies" : [ "requests<3", "rich" ] }
Other than that, this isn't a bad proposal. Generally for single-file scripts, figuring out the imports isn't too difficult but you do have the occasionally weirdly named pypi package vs installed import package.
It's just lightening the load on developers by making the parsing simpler.
