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.