I have a similar concern to Petr (and, apologies for not raising it until
now -- I realise that this PEP has been around for a while now).
Broadly, I'm concerned about the tone of the "Rejected Ideas" section. Most
of the rejected ideas seem to be along the lines of "We rejected X feature
because it was specific to Y library, and dataclasses doesn't have X
feature". I worry that the takeaway message for third-party libraries might
appear to be "Make sure your library's API has exactly the same API as
dataclasses, or your library won't be supported by type checkers".
I love the idea of generalising type-checker logic for dataclasses-esque
libraries in the way that this PEP proposes. But I worry that appearing to
send out such a message could have the effect of stifling innovation in
dataclasses-esque third-party libraries. dataclasses is still a relatively
new stdlib module, and the API is still evolving -- there were three new
parameters added to `dataclasses.dataclass` in 3.10 alone. I worry that
it's too soon to tell third-party libraries that API innovations should
stop now.
I'm sure that this wasn't the message that the PEP authors intended to send
-- I just think it might be something worth bearing in mind. I can also see
the rationale for rejecting each one of these rejected ideas -- it's very
understandable to want to avoid complicating the API for a feature that
only exists in one third-party library, and doesn't exist in dataclasses.
Perhaps a partial solution could be to add a note in the "Rationale"
section stating that features may also be added to `dataclass_transform` in
the future if they are adopted by multiple third-party libraries (i.e.,
they don't *have *to be part of the dataclasses API to be added to
`dataclass_transform`).
Best,
Alex
On Sat, Apr 23, 2022 at 9:20 AM Jelle Zijlstra
El sáb, 23 abr 2022 a las 4:26, Petr Viktorin (
) escribió: Hello, As an initial implementation that will be improved in the future, the specification in PEP 681 is fine. Feel free to add the decorator to Python 3.11 at your convenience.
Thanks Petr, that's great to hear!
I opened a PR at https://github.com/python/cpython/pull/91861 so we can get the new decorator in before the feature freeze.
However, the PEP includes several worrying recommendations like:
- we recommend that the maintainers of attrs move away from the legacy semantics and adopt auto_attribs behaviors by default. - We chose not to support this feature and recommend that attrs users avoid converters. - Attrs users should use the dataclass-standard eq and order parameter names instead.
These are probably meant as recommendations from typing-sig, but an accepted PEP represents consensus of the entire Python community. A typing PEP is not an appropriate place to make recommendations like this, especially without reaching out to the maintainer of attrs. As far as I know,the attrs and pydantic libraries are using the reference implementation, but their authors weren't consulted on the PEP itself.
Could you either change the wording (e.g. say that the unsupported features need bespoke type-checker functionality for proper type checking), or work with attrs to make the same recommendations in its documentation?
Agree that these recommendations sound overly normative. I think we should remove the recommendations and simply spell out the features that won't work with dataclass_transform(). It's up to users' own judgment what they do with that information. Erik, could you propose a change to the PEP text?
Happy typing, — Petr, on behalf of the Steering Council _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: jelle.zijlstra@gmail.com
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: alex.waygood@gmail.com