Thanks for writing up this proposal!
I like it more than the PEP 722 syntax:
- I find PEP 723 harder to mess up than PEP 722; e.g. I can easily imagine forgetting to capitalise “Dependencies” or forgetting to double the
# - I like that it mirrors pyproject.toml and you can copy paste between the two
- The use of
__pyproject__makes it easier to google (PEP 723 is already the first hit for me, while googling “python script dependencies” is not helpful) - Using a markup language makes it more obvious how to spell future extensions. For instance, I could imagine this feature being extended to allow “local” dependencies, adding entrypoints, tool specific options that dictate how the environment should be managed, other tool and file specific configuration (similar to how people love pyproject.toml for this), etc.
I did not find the “Why not TOML” part of PEP 722 convincing:
- I find TOML very human readable and friendly to people who’ve used any Python! The syntax needed here is basically just assignment of list to variable.
- I fully expect people to be able to write (or copy paste) this without even realising that it’s TOML.
- “There are many ways of writing a simple list of strings in it, and it will not be clear to inexperienced users which form to use” ← I just don’t find this convincing. This argument would apply to list literals in the Python language too! The beginners I’ve helped aren’t usually particularly confused by list syntax.
- I think the point about not really needing flexibility is correct. But a lot of the argument for TOML in my mind is for consistency; the double
#and capitalisations and un-googleableness just feels so ad hoc.
(edit: I haven’t kept up with all the PEP 723 changes after I posted this comment)