TypeAlias can now be used, add guidance #1116
Conversation
| def bar(x: Optional[str]) -> Optional[int]: ... | ||
| def baz(x: None | str) -> None: ... | ||
|
|
||
| But the following is still necessary:: |
There was a problem hiding this comment.
Is it? The only reason this would still be necessary is mypy bugs, and I don't think this doc should track exact mypy bugs.
There was a problem hiding this comment.
Well, in a way this doc must track bugs as it is a guide on how to write stubs. If it can't be used in stubs, we can't recommend to use it.
There was a problem hiding this comment.
True, but this particular bug has been fixed, and I don't think we'll be able to keep this doc up to date with the exact mypy bugs that are still active. Perhaps we should just say that edge cases may not work with all type checkers yet, and link to https://github.com/python/mypy/labels/topic-pep-604
There was a problem hiding this comment.
There are (I think) 53 files in typeshed where we still have to import Union and/or Optional due to mypy bugs. Considering how large a repository typeshed is, that isn't so many — we can probably say that PEP 604 syntax can be safely used in nearly all situations now, but that a few bugs still remain.
There was a problem hiding this comment.
Fair enough, I'll send a PR tomorrow, unless someone else wants to improve the wording? Please feel free to commit to the branch.
There was a problem hiding this comment.
Actually, we should make that a separate PR, as this is not related to type aliases.
AlexWaygood
left a comment
AlexWaygood
left a comment
There was a problem hiding this comment.
Maybe "variable aliases" instead of "regular aliases"?
| _IntList = list[int] | ||
| _StrList: TypeAlias = list[str] | ||
|
|
||
| Type checkers should also accept regular module-level or class-level aliases, |
There was a problem hiding this comment.
| Type checkers should also accept regular module-level or class-level aliases, | |
| Type checkers should also accept module-level or class-level variable aliases, |
There was a problem hiding this comment.
I agree that something more fitting than just "regular" would be a good idea, but "variable" doesn't really fit, in my opinion. For example, while class or function aliases could technically be considered variable aliases, it sounds a bit weird. Maybe we should just list the other cases? "Class, function, method, and (module- and class-level) attribute aliases".
There was a problem hiding this comment.
I see your point. I think I'd still go with "variable aliases", but I don't object massively if you stick with "regular aliases" (I think "regular aliases" is probably better than listing them all out)
| Type Aliases | ||
| ------------ | ||
|
|
||
| Use ``TypeAlias`` for type aliases (but not for regular aliases). |
There was a problem hiding this comment.
| Use ``TypeAlias`` for type aliases (but not for regular aliases). | |
| Use ``TypeAlias`` for type aliases (but not for variable aliases). |
Co-authored-by: Shantanu <[email protected]>
|
Pingety pong. |
5 participants
No description provided.