When assigning a type to more than one name using multiple assignment, none of the new names are recognized as types, and cannot be used in annotations.
I'm using Python 3.6.4 and the current mypy version from the repo (0.580-dev-80a9b8f8e362902a93606ea0aabf9c18184fef3e) with no special command-line flags.
Example code:
# Not working:
Spam1 = Ham1 = int
spam1: Spam1 # error: Invalid type "testing2.Spam1"
ham1: Ham1 # error: Invalid type "testing2.Ham1"
# Equivalent and working:
Ham2 = int
Spam2 = Ham2
spam2: Spam2
ham2: Ham2
Hm, I think this has never been discussed, so maybe the current behaviour is an implementation detail? PEP 484 is also silent about what to do here. This is easy to enable, but I am neither in favor or against this. @JukkaL @gvanrossum what do you think, should we allow this?
I don't think we should enable this. Instead, we should clarify that PEP
484 only endorses type aliases with a single assignment target.
OK, I am fine with this. @dgelessus would you like to make a PR to python/peps repo?
Just to clarify, the reason why I ran into this was because I was writing the stub for ctypes.wintypes. Many Windows types have alternate names (mostly historical), which are all mirrored in ctypes.wintypes. Because of this, wintypes.py has a number of lines like LPBOOL = PBOOL = _Pointer[BOOL] or tagPOINT = _POINTL = POINTL = POINT, which I copied over into the stub file unmodified. These can of course be split into multiple single assignment statements, and it wouldn't require an unreasonable number of extra lines, but it wouldn't exactly help readability since the original type name needs to be repeated.
I wouldn't have any issue with this if it was just a style guideline - then in the case of ctypes.wintypes I could argue "foolish consistency" and ignore it here. However if multiple assignment for type aliases is explicitly prohibited by PEP 484 and mypy, my only option is to split up all the assignments, regardless of whether it actually helps readability.
(To be clear - is the argument for disallowing type aliases by multiple assignment just stylistic, or is there another reason why it's better not to allow it? I don't know mypy's internals, but it doesn't seem like it would be very difficult to implement.)
I don't think that we want to support this. Type aliases are basically treated as a "special form" by mypy, and the syntax is restricted by design.
See also PEP 613.
Most helpful comment
Just to clarify, the reason why I ran into this was because I was writing the stub for
ctypes.wintypes. Many Windows types have alternate names (mostly historical), which are all mirrored inctypes.wintypes. Because of this,wintypes.pyhas a number of lines likeLPBOOL = PBOOL = _Pointer[BOOL]ortagPOINT = _POINTL = POINTL = POINT, which I copied over into the stub file unmodified. These can of course be split into multiple single assignment statements, and it wouldn't require an unreasonable number of extra lines, but it wouldn't exactly help readability since the original type name needs to be repeated.I wouldn't have any issue with this if it was just a style guideline - then in the case of
ctypes.wintypesI could argue "foolish consistency" and ignore it here. However if multiple assignment for type aliases is explicitly prohibited by PEP 484 and mypy, my only option is to split up all the assignments, regardless of whether it actually helps readability.(To be clear - is the argument for disallowing type aliases by multiple assignment just stylistic, or is there another reason why it's better not to allow it? I don't know mypy's internals, but it doesn't seem like it would be very difficult to implement.)