This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lukasz.langa
Recipients Ricyteach, eric.smith, lukasz.langa, methane, ned.deily
Date 2018-05-11.18:47:34
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> 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.
Date User Action Args
2018-05-11 18:47:34lukasz.langasetrecipients: + lukasz.langa, eric.smith, ned.deily, methane, Ricyteach
2018-05-11 18:47:34lukasz.langasetmessageid: <>
2018-05-11 18:47:34lukasz.langalinkissue33453 messages
2018-05-11 18:47:34lukasz.langacreate