-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Documenting the Any trick #11094
Comments
Related: #7870 |
Unlike #7870, we could just introduce a type alias for |
I have mixed thoughts about the On the one hand, seeing On the other hand, the return type may actually be shown as For naming the type alias, I think we should think about people new to Python who just want to parse something with a regex. Do we want their IDE to show |
I believe that showing them something other than Also, making this easier greppable is an advantage for us maintainers. |
TIL about "the Any trick" (I had seen it, but thought it was just for documentation purposes). As for the alias name, I am partial to (I also have to plug this as yet another ref to AnyOf[_T, None]) |
I like |
Hmm even without AnyOf really working we could have our own AnyOf,
May need a better name here though. Avoid 3.12+ syntax,
If you want 1+ arguments instead of exactly 2 change S to *S. This does still require mypy/other type checkers support |
The intent is for S to be unused and T to be the primary type. So if something returns T most of time but may also return S and we don’t want to include S as part of Union you can use that definition of AnyOf. So it’s strict in first argument and latter arguments are only there for documentation. For your test example you should flip order. edit: type AnyOf[T, S] = T
test: AnyOf[datetime.datetime, str]
_ = test.astimezone # No error, while document test may occasionally be str edit2: Maybe a name like |
Just to clarify: I'm still in favor of using a type alias in some way, although documenting it in some other way would be better than the status quo. |
Writing textual documentation with accurate terminology isn't my forte, but if no one else wants to take this I can get a PR started basing myself off of @Akuli 's description here #7770 (comment) |
Also condense the explanation in CONTRIBUTING to what's actionable for the user. Closes: python#11094
We have explained the Any trick to contributors and users several times, usually related to
re
stubs, but also a few times in other cases, like #8069 and #10564 (comment).Maybe we should explain it in CONTRIBUTING.md (or some other file) and comment usages of the Any trick, something like this?
The text was updated successfully, but these errors were encountered: