[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

[Łukasz Langa]

Łukasz Langa <lukasz at langa.pl> added the comment:

> I think we've learned lesson that we shouldn't use typing in modules other than typing...

This is a blanket statement that as hurtful as it is factually incorrect.  Let me address the latter.

1. Dataclasses are entirely dependent on annotations *as described by the typing module*.   While it would be entirely possible for users to pass an arbitrary expression as an annotation to denote it's a field of the dataclass, then it's confusing the reader of that code... what's the point?  The fact that dataclasses isn't itself importing `typing` is an implementation detail of dataclasses.

2. The problem isn't even specific to `typing` but stringified type annotations in general.  If the magic sentinel annotation came from the dataclasses module, it would be just as tricky to get it right as it is now when this sentinel lives in `typing`.

3. singledispatch now also allows registering functions that are type-annotated.  In fact, that is a nicer API than the old one.  That usage also imports `typing`.  I don't see how this is a problem.


> If it is really needed, I think we should only allow "typing.ClassVar".  All other prefixes seems ambiguous.

I came up with "typing", "t", and straight "ClassVar" by grepping through typed codebases I work with.  I agree that "t" is rather arbitrary so I'm totally fine with leaving that one out.

----------
assignee: eric.smith -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33453>
_______________________________________