Is there a reason, why the __pyproject__ variable is not a dict but a toml string?

I think they do kind of answer that under the "Why not use (possibly restricted) Python syntax?".

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

Ah okay, I read this but I've understood it in another way. I thought they meant using multiple variables could become a problem. But I guess it makes some sense to not parse the python ast tree but to parse with a regex.

Maybe because then you can just inline a pyproject text without any extra effort and the existing tooling for pyproject parsing can work in both cases?

Yeah copying a pyproject.toml seems like a valid case. But I'd guess that the toml will be parsed to something like a dict anyway after reading the file/string.

It's probably because pyproject.toml is the direction in which the python ecosystem is going.

On that note, I will never understand why they chose .toml instead of just json or yaml..

YAML is one of the most ambiguous formats out there, and definitely an overkill for what's needed to describe metadata.

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.

> On that note, I will never understand why they chose .toml instead of just json or yaml..

https://peps.python.org/pep-0518/#other-file-formats

I think "easy for humans to edit" is where I mostly disagree with. To this day I have not worked with anyone that understood the .toml format.

Hey. I think I understand the .toml format. What do you want to know?

How much time have you spent towards TOML vs -- say -- YAML?

More editable than JSON and far simpler than YAML.

---

The Rust ecosystem also uses TOML.

Thanks this also gave another reason why they didn't use a dict for configuration https://peps.python.org/pep-0518/#python-literals

YAML is only fun when you're not tripping in the numerous landmines in the way: https://noyaml.com/

Yes, but you can write a pyproject toml file also as a python dictionary.

Instead of:

[project] requires-python = ">=3.11" dependencies = [ "requests<3", "rich", ]

You could write:

{ "project": { "requires-python":">=3.11", "dependencies" : [ "requests<3", "rich" ] }

No way !

Gotta think carefully about this... Might upset some coworkers

It does seem like over-complicating things for a dynamic language not to use itself as the standard configuration format.

For some additional context: PEP 722[1] proposes a similar technique, but only for the script's requirements (and not the full TOML-formatted package metadata).

[1]: https://peps.python.org/pep-0722/

PEP 723 should be preferred over 722. Using a .toml format makes a lot more sense over the arbitrary `Script Dependencies:` line in a comment block.

Both come with upsides and downsides: it's worth reading the discussion threads[1][2] on both!

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

This would be really great. I could see if pairing well with a tool like pipx for quickly sharing utility scripts.

This will be useful, and definitely handy when sharing random scripts with a defined structure for its requirements. I've struggled to give scripts to non-developers to run recently and between getting them to configure a virtualenv and install dependencies by hand to using `pipx` it's been a pain so hopefully this will alleviate some if it in the future.

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

It's interesting that they tested for AI code completion compatibility. It makes sense as AI code completion is now a big part of tooling and standards should accomodate for common tools.

AI code completion is a complete grift.

That’s funny because literally today I wrote a script runner that implements PEP 722

One thing I don't quite get is why the proposal here is so insistent on triple quoted strings only. Shouldn't a \n formatted string also be considered valid? Its practically just a string after all.

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.

The syntax is restricted so the toml content can be extracted without actually parsing the Python file, a regex is enough.

I think the reason for being so specific about using tripple quoted strings is that this stuff needs to be parsed out without running it through the interpreter. e.g. pip needs to be able to fish out the pyproject.toml data to install dependencies before running the script is even going to work.

It's just lightening the load on developers by making the parsing simpler.

Will it be part of the Python distribution (3.12?) or a specification for an independent package? Is there already an implementation, apart from the GitHub repository referenced in the article?