Other libraries presumably came up with their own data transfer objects prior to the introduction of dataclasses. But dataclasses are here, and are now the standard for data structures for Python. So, a part of my thinking is, yes, somehow existing libraries should adapt in some way. (I don't see much reason to support those who have no interest in understanding dataclasses.)

As I am naive about Python static type checking, I would suggest a Protocol that defines methods that dataclass proper and others should implement. While I'm at it, I would then also deprecate `is_dataclass` and rely on subclass checking against the protocol. Adapting other implementations could be just to add any additional "dataclass" semantics over what they've already built. 


On Sat, 2021-04-24 at 15:54 +0000, Eric Traut wrote:
Yes, it's possible to use `TYPE_CHECKING` to get close to the desired type checking semantics in some cases (at least those that use decorator functions to transform the original class), but I don't think this solution is adequate. Shantanu, you are a very experienced and clever developer. Most Python developers would not come up with this solution.

The vast majority of Pylance users (I would guess >95%) are not interested in type checking but _are_ interested in high-quality completion suggestions and tooltip-based documentation during editing. These features rely on type information under the covers, but these users generally don't have any understanding of (or interest in understanding) Python type annotations. They simply expect it to work — in their code editor and in they Jupyter notebooks.

Of the Pylance users who _are_ interested in type checking (a number that is growing all the time!), I would estimate that >90% of them are not sophisticated enough in their understanding of types to think of a solution like the one you suggested above. They expect type checking to "just work" with all of the popular libraries. That's not an unreasonable expectation, in my opinion.

Paul, I'm not sure I understand what you mean by "implement their data objects as dataclasses". Are you suggesting that the authors of all of these popular libraries should reimplement their library's functionality by subclassing from dataclass in some manner? I don't think that's a realistic ask. It would be a large undertaking, would be a breaking change in terms of the library's interface (at least for those that are metaclass-based), would introduce other subtle incompatibilities for programs that use these libraries (and other libraries that build on these libraries), and it would take years for the Python community to adopt these new versions. I'm also skeptical that all of these libraries could be built on top of dataclass because some of the functionality they include (such as pydantic's runtime type checking) likely does not compose well with the implementation of dataclass. So if I understand you correctly, I don't think that proposal would achieve the goals I'm trying to achieve here. If I misinterpreted your suggestion, please elaborate.


Eric Traut
Contributor to Pyright & Pylance
Microsoft Corp.
Typing-sig mailing list -- typing-sig@python.org
To unsubscribe send an email to typing-sig-leave@python.org
Member address: pbryan@anode.ca