Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

gh-105499: Merge typing.Union and types.UnionType#105511

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
JelleZijlstra merged 52 commits intopython:mainfromJelleZijlstra:unifyunion
Mar 4, 2025

Conversation

@JelleZijlstra
Copy link
Member

@JelleZijlstraJelleZijlstra commentedJun 8, 2023
edited by github-actionsbot
Loading

ParthSareen and shahshahii reacted with thumbs up emojishahshahii and bswck reacted with hooray emoji
@AlexWaygood
Copy link
Member

Would we be able to get rid oftyping._make_union, and just haveTypeVar etc. callUnionType.__class_getitem__ directly?

@JelleZijlstra
Copy link
MemberAuthor

Would we be able to get rid oftyping._make_union, and just haveTypeVar etc. callUnionType.__class_getitem__ directly?

Yes

AlexWaygood reacted with hooray emoji

@AlexWaygood
Copy link
Member

Instead of deletingtyping.Union completely, addingUnionType.__class_getitem__, and makingtyping.Union an alias fortypes.UnionType, I wonder if we could just changetyping.Union so that it's a special form that just returns instances ofUnionType:

fromoperatorimportor_fromfunctoolsimportreduce@_SpecialFormdefUnion(self,parameters):returnreduce(or_,parameters)

That would avoid the issue of "Should we renametypes.UnionType to beUnion", as we'd keep them as distinct objects.

But I know your plan is to deal with handling forward refs in| expressions later, which would mean that^ idea above wouldn't work right now (unions involving forward references would break).

So perhaps you could instead expose a_secret_undocumented_constructor method fortypes.UnionType (we can bikeshed over the name), and then just do

@_SpecialFormdefUnion(self,parameters):returntypes.UnionType._secret_undocumented_constructor(parameters)

Or we could just expose the constructor oftypes.UnionType, of course.

@AlexWaygood
Copy link
Member

AlexWaygood commentedJun 8, 2023
edited
Loading

Also you can now get rid of this function as part of this PR; prior callers of the function can now just useisinstance() checks againsttypes.UnionType:

def_is_union_type(cls):
fromtypingimportget_origin,Union
returnget_origin(cls)in {Union,types.UnionType}

@JelleZijlstra
Copy link
MemberAuthor

That would avoid the issue of "Should we renametypes.UnionType to beUnion", as we'd keep them as distinct objects.

I'd rather not keep them as distinct objects, though; that means we still have two objects that to a user look like the same thing. Plus, we'd haveget_origin(Union[int, str]) != Union.

moi90 reacted with thumbs up emoji

@AlexWaygood
Copy link
Member

AlexWaygood commentedJun 8, 2023
edited
Loading

I guess one of my reservations here is thatUnionType ends up looking like apretty weird type. You can't construct instances of it directly:

>>>from typesimport UnionType>>> UnionType(int,str)Traceback (most recent call last):  File "<stdin>", line 1, in <module>TypeError: cannot create 'types.UnionType' instances

...Except wait, you can, we now have a "secret__class_getitem__ backdoor" to create instances directly:

>>> UnionType[int,str,bytes]int | str | bytes

It's very unusual for__class_getitem__ to just directly return instances of the class, and it feelsreally weird to make that theonly way you're allowed to construct instances of the class.

Maybe that means we should just expose the constructor as well as adding__class_getitem__...?

Plus, we'd haveget_origin(Union[int, str]) != Union.

Good point, that would indeed be confusing.

@JelleZijlstra
Copy link
MemberAuthor

I can make the constructor work. Should it take *args and union them all together?

@AlexWaygood
Copy link
Member

I can make the constructor work. Should it take *args and union them all together?

That makes sense to me!

Copy link
Member

@AlexWaygoodAlexWaygood left a comment
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

This looks great, in my opinion. From a design perspective, the only weirdnesses I can see are that both of these become valid at runtime:

fromtypesimportUnionTypefromtypingimportUnionUnionType[int,str]Union(int,str)

I can live with that, though, and hopefully linters can flag those uses. (Type checkers almost certainly will, anyway.) On our side, we can just not document that you can do either of those things.

x<y
# Check that we don't crash if typing.Union does not have a tuple in __args__
y=typing.Union[str,int]
y.__args__= [str,int]
Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

.__args__ is no longer writable.


bt=BadType('bt', (), {})
bt2=BadType('bt2', (), {})
# Comparison should fail and errors should propagate out for bad types.
Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

With the new code there are fewer code paths that trigger the equality comparison.

@JelleZijlstra
Copy link
MemberAuthor

It's been long enough, I'm planning to merge this once the tests pass again.

@JelleZijlstraJelleZijlstra added the 🔨 test-with-buildbotsTest PR w/ buildbots; report in status section labelMar 3, 2025
@bedevere-bot
Copy link

🤖 New build scheduled with the buildbot fleet by@JelleZijlstra for commitcab69f0 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F105511%2Fmerge

If you want to schedule another build, you need to add the🔨 test-with-buildbots label again.

@bedevere-botbedevere-bot removed the 🔨 test-with-buildbotsTest PR w/ buildbots; report in status section labelMar 3, 2025
@JelleZijlstraJelleZijlstra merged commitdc6d66f intopython:mainMar 4, 2025
113 of 119 checks passed
@hugovk
Copy link
Member

This PR causes a potential regression:#131933.

JelleZijlstra added a commit to JelleZijlstra/cpython that referenced this pull requestMar 31, 2025
Leftover frompython#105511 I believe. GitHub code search found no usages otherthan copies of typing.py and lists of stdlib functions.
JelleZijlstra added a commit that referenced this pull requestMar 31, 2025
Leftover from#105511 I believe. GitHub code search found no usages otherthan copies of typing.py and lists of stdlib functions.
seehwan pushed a commit to seehwan/cpython that referenced this pull requestApr 16, 2025
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>Co-authored-by: Ken Jin <kenjin@python.org>Co-authored-by: Carl Meyer <carl@oddbird.net>
seehwan pushed a commit to seehwan/cpython that referenced this pull requestApr 16, 2025
Leftover frompython#105511 I believe. GitHub code search found no usages otherthan copies of typing.py and lists of stdlib functions.
serhiy-storchaka added a commit to serhiy-storchaka/cpython that referenced this pull requestSep 16, 2025
…s.UnionType (python#105511)"This reverts commitd1db43c.This reverts commit0f511d8.This reverts commitdc6d66f.
serhiy-storchaka added a commit to serhiy-storchaka/cpython that referenced this pull requestSep 16, 2025
…s.UnionType (python#105511)"This reverts commitd1db43c.This reverts commit0f511d8.This reverts commitdc6d66f.
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@gvanrossumgvanrossumgvanrossum left review comments

@Fidget-SpinnerFidget-SpinnerFidget-Spinner left review comments

@kumaraditya303kumaraditya303kumaraditya303 left review comments

@carljmcarljmcarljm approved these changes

@ericvsmithericvsmithAwaiting requested review from ericvsmithericvsmith is a code owner

@markshannonmarkshannonAwaiting requested review from markshannon

@AlexWaygoodAlexWaygoodAwaiting requested review from AlexWaygoodAlexWaygood is a code owner

+1 more reviewer

@Gobot1234Gobot1234Gobot1234 left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

9 participants

@JelleZijlstra@AlexWaygood@carljm@bedevere-bot@hugovk@gvanrossum@Fidget-Spinner@Gobot1234@kumaraditya303

[8]ページ先頭

©2009-2025 Movatter.jp