PEP 735: Mark as Final

[sirosen]

The canonical doc link was already merged (slightly out-of-order), but this change should "true it up".

As a packaging PEP, several of the checklist items are blank as not-applicable.

• Final implementation has been merged (including tests and docs)
• PEP matches the final implementation
• Any substantial changes since the accepted version approved by the SC/PEP delegate
• Pull request title in appropriate format (PEP 123: Mark Final)
• Status changed to Final (and Python-Version is correct)
• Canonical docs/spec linked with a canonical-doc directive
  (or canonical-pypa-spec for packaging PEPs,
  or canonical-typing-spec for typing PEPs)

---

@pfmoore, there's only one thing which I learned during implementation and which I think is worth sharing. I do not think it's material to the PEP itself, but it is something which might impact future discussions.

There's a callout in the PEP and the spec doc about not doing more validation than you need to, in order to allow multiple tools and tool versions to coexist even if the spec evolves in the future.
In Python, this is very easy to support -- load the TOML data, but only read sections as you need them. In Rust, by contrast, when I went to contribute to the pyproject.toml parser, I found that it would have required entirely reworking the way that pyproject.toml is treated.

That parser is eagerly loading and validating the whole pyproject.toml file, as it's just a better fit for the language. In retrospect, it seems obvious that the "natural fit" for reading a datastructure from TOML or JSON in less dynamic languages is to construct a tree of strict types and load the data into those types.
For two reasons, I didn't try to rewrite the Rust parser. (1) I'm a Rust novice, so I'm not confident I could do it well without more time to learn. (2) I'm not sure that the Rust consumers would actually want a lazy data model for pyproject.toml in the first place.

So that's the one place where the implementations deviated from the PEP a little -- a SHOULD which is not being followed uniformly. I don't think the PEP itself needs any change.
But if anyone makes the assumption that a user of pyproject.toml isn't reading the whole file, it's worth knowing that the Rust tools are.

---

📚 Documentation preview 📚: https://pep-previews--4213.org.readthedocs.build/

[pfmoore]

So that's the one place where the implementations deviated from the PEP a little -- a SHOULD which is not being followed uniformly. I don't think the PEP itself needs any change.

Agreed, this is perfectly fine - tools are expected to do what's best for their use case when dealing with a SHOULD in a spec. If it's a problem to consumers that the rust library pre-validates everything, that's a usability matter for the library in question to deal with, and doesn't impact the spec directly.

[hugovk]

Thank you, and congratulations on shepherding your first PEP all the way to the finish line! 🎉