Beyond the API already proposed in PEP 557, this would mean adding:

* dataclasses.ClassVar (as proposed above)
* dataclasses.Any (probably just set to the literal string "dataclasses.Any")
* dataclasses.NamedTuple (as a replacement for typing.NamedTuple)
* potentially dataclasses.is_class_var (instead of dataclasses
implicitly snooping in sys.modules looking for a "typing" module)

In effect, where we now have "typing" and "typing_extensions", we'd
instead have "dataclasses" in the standard library (with the subset of
annotations needed to define data record classes), and "typing" as an
independently versioned module on PyPI.

I'm not so keen on this because I think some things in typing (such as NamedTuple) probably deserve to be in the collections module. And some of the ABCs could probably also be merged with collections.abc but doing this correctly and not all at once would be quite difficult.

I do think the typing concepts should be better integrated into the standard library. However, a fair amount of the clases you list (such as NamedTuple) are in of themselves dependent on parts of typing.

Cheers,

Ethan

I think such an approach could address a few problems:

- the useful-at-runtime concepts (in dataclasses) would be clearly
separated from the static-type-analysis enablers (in typing)
- type hints would still have a clear presence in the regular standard
library, but the more complex parts would be opt-in (similar to
statistics vs SciPy, secrets vs cryptography, etc)
- as various concepts in typing matured and became genuinely stable,
they could potentially "graduate" into the standard library's
dataclasses module

Cheers,
Nick.

--
Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/ethan%40ethanhs.me