Python Steering Council hat: Thanks for the well written PEP and thorough discussion here. We have reviewed and discussed this PEP and we are unfortunately not finding ourselves leaning towards accepting it today. (The question the SC would like to see answered to change our future selves mind is at the end)
Reasoning:
- A
dataclasses.fieldconverter adds complexity (additional spooky action at a distance and a concept going further than a “just a struct” mental model). - There are already multiple ways to do this even if they involve more lines (
__init__, alternate constructors, etc). - For users who really want converters rather than the additional lines of code: They can already use third party dataclass-like libraries (presumably
attrs) providing the feature today instead of waiting for CPython 3.13+.
One of our guiding general themes is that there is less reason for every feature to be done in the standard library now than in years past. Virtually all Python applications are built upon many third party packages from our ecosystem today.
Q: Is there a compelling reason for dataclass field converters to be in the standard library that we’re just missing?
It is good to see people piping up on this thread who do want the feature. It would be interesting to know how important that is and if you already do, or why you don’t, use something like attrs today just to have it.
We’ll keep the steering-council pep-712 issue open for a while as a reminder to observe any further discussion (and let the next elected SC make the final decision).
-gps for the 2023 Python Steering Council