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.
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?
Happy typing, — Petr, on behalf of the Steering Council
El sáb, 23 abr 2022 a las 4:26, Petr Viktorin (encukou@gmail.com) 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
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 jelle.zijlstra@gmail.com wrote:
El sáb, 23 abr 2022 a las 4:26, Petr Viktorin (encukou@gmail.com) 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
Petr, thanks for the update. The SC recommendations make sense.
Alex, I understand your point, but keep in mind that PEPs are about standardization and consensus. While we don't want to stifle innovation, we also want to encourage conformity unless there's a good reason for divergent approaches. Without standards, it is very difficult to provide good tooling.
Many of the features mentioned in the "Rejected Ideas" section of PEP 681 are vestigial or are used relatively infrequently. IMO, there should be a relatively high bar for a feature becoming "standardized" in a programming language, standard library, or type system. As you point out, the stdlib dataclass continues to evolve — in some cases influenced by innovations that originated in these other dataclass-esque libraries. I think this is a really healthy approach. As new innovations meet the bar for standardization, they can flow into stdlib dataclass, and dataclass_transform will automatically inherit these additions.
I like your suggestion for adding a note in the "Rationale" section that talks about the anticipated evolution of dataclass_transform.
-Eric
-- Eric Traut Contributor to Pyright & Pylance Microsoft
On 24. 04. 22 23:05, Eric Traut wrote:
Petr, thanks for the update. The SC recommendations make sense.
Alex, I understand your point, but keep in mind that PEPs are about standardization and consensus. While we don't want to stifle innovation, we also want to encourage conformity unless there's a good reason for divergent approaches. Without standards, it is very difficult to provide good tooling.
Many of the features mentioned in the "Rejected Ideas" section of PEP 681 are vestigial or are used relatively infrequently. IMO, there should be a relatively high bar for a feature becoming "standardized" in a programming language, standard library, or type system. As you point out, the stdlib dataclass continues to evolve — in some cases influenced by innovations that originated in these other dataclass-esque libraries. I think this is a really healthy approach. As new innovations meet the bar for standardization, they can flow into stdlib dataclass, and dataclass_transform will automatically inherit these additions.
I'd put it differently: I see dataclasses as the *lowest common denominator* rather than the current best way to do things. As a lowest common denominator it's a perfect target for standardization, but it cannot cover all use cases.
In particular, the "converters" feature in attrs is very useful, and far from vestigial -- even if dataclasses might never include it.
On Sun, Apr 24, 2022, at 4:20 PM, Alex Waygood wrote:
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".
Sorry to chime in three weeks late on this. I had a long thread with Eric Traut and Erik De Bonte on this which can be seen at https://github.com/microsoft/pyright/discussions/2958 . At the end of the day, the current state of pep646 will be able to work for what we're doing in SQLAlchemy. However, as the language that codified the behavior of descriptors via the "transform_descriptor_types" field was removed and was not replaced with any new language detailing the current behavior of dataclasses, which is that they do in fact honor descriptors when generating __init__ (although it seems to be by accident and not tested?) I do feel there's less of a guarantee that all typing tools that implement pep-681 are going to work with SQLAlchemy, and whether or not I will have to make a case to these projects that they should be handling descriptors in this specific way since IIUC it's not codified anywhere.
Eric's rationale for being very conservative about introducing things that aren't in dataclasses seems to be as he mentions in this thread the need for standardization but also that they really want the pep to be accepted.
At the end of the day on that discussion, my initial impressions of pep-681 changed, I at first thought it would be an open-ended spec that allows for classes that want to generate `__init__` methods arbitrarily, and at the end I realized it pretty much wants the "Dataclass way" to be what's provided, including details like the names of the arguments on "field" objects. I'd be happy if this pep, or future peps that build on it, would be more open to flexibility in that more than just "does dataclasses do X?" is not the only question asked, however for the moment SQLAlchemy will be able to work just fine with what's provided, as long as the "descriptor" behavior does not change.
* dataclasses…do in fact honor descriptors when generating __init__ (although it seems to be by accident and not tested?)
The work to document dataclass’s behavior with descriptor-typed fields is being tracked here: https://github.com/python/cpython/issues/91330
I would expect type checkers to honor the decisions made there for dataclass_transform as well.
-Erik
* Erik, could you propose a change to the PEP text?
I just created https://github.com/python/peps/pull/2555 to address these issues.
-Erik
Hello, With the latest wording changes, PEP 681 – Data Class Transforms is now fully accepted. Feel free to mark it as such at your convenience.
Happy typing, — Petr, on behalf of the Steering Council
On 23. 04. 22 13:26, Petr Viktorin wrote:
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.
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?
Happy typing, — Petr, on behalf of the Steering Council
Hi,
Side note: it would be nice to add "typing: " prefix or mention "type annotation" or "type check" in the title of PEPs which are about that.
Just from the PEP title, it's hard *for me* to guess that it's about type annotations.
Examples of other PEP titles which confused me:
PEP 612 – Parameter Specification Variables PEP 645 – Allow writing optional types as x? PEP 646 – Variadic Generics PEP 647 – User-Defined Type Guards PEP 673 – Self Type PEP 675 - Arbitrary Literal String Type PEP 677 – Callable Type Syntax
First, I understood that "Arbitrary Literal String Type" was adding a new built-in types for "literal strings" :-) Nope. It's just about type annotations ;-)
From what I understood, the purpose of these PEPs outside type annotations is limited or non existent :-)
Victor
On Mon, Jun 6, 2022 at 2:51 PM Petr Viktorin encukou@gmail.com wrote:
Hello, With the latest wording changes, PEP 681 – Data Class Transforms is now fully accepted. Feel free to mark it as such at your convenience.
Happy typing, — Petr, on behalf of the Steering Council
On 23. 04. 22 13:26, Petr Viktorin wrote:
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.
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?
Happy typing, — Petr, on behalf of the Steering Council
Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/R4A2IYLG... Code of Conduct: http://python.org/psf/codeofconduct/
+1. Glad it's not just me
On 6/6/2022 2:36 PM, Victor Stinner wrote:
First, I understood that "Arbitrary Literal String Type" was adding a new built-in types for "literal strings" :-) Nope. It's just about type annotations ;-)
I was also excited about the new built-in type :-)
Pablo is already separating the PEPs in new release announcements (or has at least agreed to, not sure any releases have happened since I asked).
But with the amount of work going on in separate venues these days, separating "CPython implementation" from "Language specification" from "Typing specification" would be helpful. (Packaging is already separate, but doesn't appear in release announcements anyway.)
Cheers, Steve
or has at least agreed to, not sure any releases have happened since I
asked). I did:
https://www.python.org/downloads/release/python-3110b3/#:~:text=3.11.0b3%20i... .
On Mon, 6 Jun 2022 at 19:13, Steve Dower steve.dower@python.org wrote:
+1. Glad it's not just me
On 6/6/2022 2:36 PM, Victor Stinner wrote:
First, I understood that "Arbitrary Literal String Type" was adding a new built-in types for "literal strings" :-) Nope. It's just about type annotations ;-)
I was also excited about the new built-in type :-)
Pablo is already separating the PEPs in new release announcements (or has at least agreed to, not sure any releases have happened since I asked).
But with the amount of work going on in separate venues these days, separating "CPython implementation" from "Language specification" from "Typing specification" would be helpful. (Packaging is already separate, but doesn't appear in release announcements anyway.)
Cheers, Steve _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/3VJEOP2V... Code of Conduct: http://python.org/psf/codeofconduct/
-
Alex Waygood -
Eric Traut -
Erik De Bonte -
Jelle Zijlstra -
Mike Bayer -
Pablo Galindo Salgado -
Petr Viktorin -
Steve Dower -
Victor Stinner