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.