-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Improve sphinx.util.typing
[part 2]
#12257
Conversation
sphinx.util.typing
sphinx.util.typing
[part 2]
sphinx.util.typing
[part 2]sphinx.util.typing
[part 2]
I haven't had as much time as I had hoped, so I'll outline some thoughts rather than pushing an update to the PR. I don't think this is in a state to merge, currently. Further, I think it tries to do too many things, and is confusing in so doing. I would prefer to have distinct PRs introducing the TypeGuard changes, mock changes in autodoc tests, sentinel changes in util.inspect, stylistic refactors, and the bug fix. It's perhaps a bit overkill to have 5 PRs in total, but at least a good degree of clarity in the individual commits such that a reviewer can follow along would be a first step -- it is currently hard to verify what each refactor does as so much of the line changes in the commit, and this hard to verify that the changes don't have any unintended effects or logical errors etc. Sorry for the less immediately positive feedback. I've started on these changes locally, but realistically won't be able to finish them before Sunday. A |
Oh it's fine. I can do the typeguards separately. There are some changes that need to be synced because of the tests but I think I can postpone the bug fix itself and its refactorization. I just needed something to support typing_extensions.Unpack and since it didn't take me too much time I went brr in 1 PR. Now, I'm in the middle of writing my thesis so I'll be less present until late may (my deadline). |
I think I'll do:
|
In terms of the 7.3 release, I've pushed a subset of the changes here but I think best to leave the rest for later. A |
I actually separated the PR yesterday locally so I'll just open them today |
This one is built on top of #12256. It would help when I want to support
typing_extensions.Unpack
. It also cleans up some old code that, honestly, was hard to read.Oh by the way, there was a bug here:
This portion of the code would never be evaluated since
cls.__args__
contains types. On the other hand,but this would render
Union[None, int]
asUnion[None, int]
instead ofOptional[int]
. For Union types written in|
style, I will keep the order so that it is consistent with Python 3.10 representation (int | None
is printed as is andNone | int
asNone | int
). For old-style unions, I'm not sure whether I should only put Optional if None is at the end or put Optional for the whole Union so I'm open to suggestions (for now, it just removes the None-like values, make them an Union, and put an optional around it).Note:
Literal[None]
are kept as is since they are also rendered differently in native Python (int | Literal[None] == Union[int, Literal[None]]
vsint | None == int | None
)