You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a pattern I'm using while adding MyPy to a large existing codebase, where I don't have time to investigate the type or the type is non-trivial.
from typing import Any as TbdType.
I propose adding an alias TbdType for Any in mypy and including a suggestion for this use in the documentation. TbdType is sufficiently unlikely to exist in any code aside from this use that it's a useful search key.
This way users will be able to search more easily later for cases where types were TRULY "Any" versus not known at the time and skipped.
As an extension of this, another alias could be provided for "this type is complex enough that MyPy doesn't currently support typing this", so users could periodically review their code for cases like this as MyPy improves. This could be called AwaitingType, AwaitingSupportForType, UnsupportedType, or something like that.
This proposal is probably a better fit for https://github.com/python/typing since you're proposing to change the typing module and PEP 484 rather then mypy itself.
That said, idk if making that change is really necessary? If you're trying to eliminate redundancy, you could always create your own custom_types.py file where you define those aliases and grep for them later on -- I think that should basically support your use case without requiring changes to the standard library?
I also think that you can easily do this yourself if you like this convention (I don't particularly, and we have over 800,000 lines of code annotated so far at Dropbox). So I think we should just reject the feature request.
Activity
Michael0x2a commentedon Jul 19, 2017
This proposal is probably a better fit for https://github.com/python/typing since you're proposing to change the
typingmodule and PEP 484 rather then mypy itself.That said, idk if making that change is really necessary? If you're trying to eliminate redundancy, you could always create your own
custom_types.pyfile where you define those aliases and grep for them later on -- I think that should basically support your use case without requiring changes to the standard library?ilinum commentedon Jul 19, 2017
This seems like a duplicate of #3712
gvanrossum commentedon Jul 19, 2017
I also think that you can easily do this yourself if you like this convention (I don't particularly, and we have over 800,000 lines of code annotated so far at Dropbox). So I think we should just reject the feature request.