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

Do not emit unreachable warnings for lines that returnNotImplemented.#20083

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

Conversation

@tyralla
Copy link
Collaborator

I think no one has complained so far. I just encountered this (in my understanding) lack inTypeChecker.is_noop_for_reachability working on#20068.

@tyrallatyralla requested a review fromA5rocksOctober 17, 2025 21:16
@github-actions
Copy link
Contributor

Diff frommypy_primer, showing the effect of this PR on open source code:

yarl (https://github.com/aio-libs/yarl)+ yarl/_url.py:550: error: Unused "type: ignore" comment  [unused-ignore]

Copy link
Collaborator

@A5rocksA5rocks 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.

I think this makes sense to me, even if it complicates the general idea of what exactly is exempt from unreachability warnings. (I guess now it's "anyway to bail out is OK"?)

I can also see this being unnecessary :^). Given nobody has complained, I'm not sure we really need to add this as a feature (since that's ultimately what this is).

Copy link
Collaborator

@sterliakovsterliakov left a comment

Choose a reason for hiding this comment

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

I think this is a good idea. See#363 (yes, three-digit issue number!) - this removes anunreachable warning from the "should be fine" snippet there. I guess it has never been explicitly reported only because--warn-unreachable is hidden too well, many users aren't even aware that it exists.

@tyralla
Copy link
CollaboratorAuthor

I think this is a good idea. See#363 (yes, three-digit issue number!) - this removes anunreachable warning from the "should be fine" snippet there.

Wow, I overlooked this dinosaur. That's a nice tool you have!

InterpretingNotImplemented asAny seems not to be the only problem. I just played around a little. Mypy does not predict the following crash:

classA1:x=1def__add__(self,o:A1)->float:ifisinstance(o,A1):returnself.x+o.xreturnNotImplementedclassA2:x=2def__add__(self,o:A2)->float:returnself.x+o.xclassB:y=3def__radd__(self,o:A1|A2)->float:returnself.y+o.xA1()+B()# worksA2()+B()# fails  (undetected by Mypy)

I will try to find a fix for this as soon as I have some spare time.

I guess it has never been explicitly reported only because--warn-unreachable is hidden too well, many users aren't even aware that it exists.

Yes, I agree. As soon as--warn-unreachable will be included in--strict, it will likely be discussed more frequently.

I think this makes sense to me, even if it complicates the general idea of what exactly is exempt from unreachability warnings. (I
I can also see this being unnecessary :^). Given nobody has complained, I'm not sure we really need to add this as a feature (since that's ultimately what this is).

It would say it is more of a fix than a feature, becausereturn NotImplemented is reachable, and so the current warning is wrong.

@tyralla
Copy link
CollaboratorAuthor

Thanks for the reviews!

@ilevkivskyiilevkivskyi merged commitc2a82b9 intopython:masterOct 19, 2025
20 checks passed
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@ilevkivskyiilevkivskyiilevkivskyi approved these changes

@hauntsaninjahauntsaninjaAwaiting requested review from hauntsaninja

+2 more reviewers

@A5rocksA5rocksA5rocks approved these changes

@sterliakovsterliakovsterliakov approved these changes

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.

4 participants

@tyralla@ilevkivskyi@A5rocks@sterliakov

[8]ページ先頭

©2009-2025 Movatter.jp