Skip to content

Rename allow_redefinition to allow_redefinition_old#373

Closed
chdemko wants to merge 2 commits into
dosisod:masterfrom
chdemko:chdemko-patch-1
Closed

Rename allow_redefinition to allow_redefinition_old#373
chdemko wants to merge 2 commits into
dosisod:masterfrom
chdemko:chdemko-patch-1

Conversation

@chdemko
Copy link
Copy Markdown

@chdemko chdemko commented Mar 31, 2026

Fix #372

Copy link
Copy Markdown

@cgoldberg cgoldberg left a comment

Choose a reason for hiding this comment

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

This change would require pinning Mypy in refurb to >=1.20.0 or else it will break environments that have an older version installed.

Maybe:

try:
    opt.allow_redefinition_old = True
except AttributeError:
    opt.allow_redefinition = True

@dosisod
Copy link
Copy Markdown
Owner

dosisod commented Mar 31, 2026

@cgoldberg your try/catch method would be preferable, as lots of people use older versions of MyPy.

In regards to Refurb's use of MyPy's internal classes, see python/mypy#16497 (comment):

There is also the bigger question of how 3rd parties should safely use Mypy internals (or if they even should in the first place). Currently Mypy internals are not versioned and can change with any release. In addition, certain parts of Mypy are hard/impossible to use outside of Mypy itself, whether that's because they don't work, crash, or require lots of moving parts because they weren't meant to be used in a stand-alone environment. I know that standardizing/stabilizing Mypy's internals so that 3rd parties can use them is probably not a major priority, but I thought I would bring it up to gauge how you all feel about it. I could elaborate more but I want to keep this short. I can open a separate issue for this if need be.

MyPy does not -- nor should they, necessarily -- use semantic versioning for their internal APIs, because they aren't meant to be used directly by 3rd party libraries. This means that tools like Refurb will have to be on the ball with new releases. There should probably be a cronjob that runs CI against the latest MyPy commit, that way these sorts of issues are detected before a MyPy release is published.

@cgoldberg
Copy link
Copy Markdown

There should probably be a cronjob that runs CI against the latest MyPy commit, that way these sorts of issues are detected before a MyPy release is published.

I added that in #374

@chdemko
Copy link
Copy Markdown
Author

chdemko commented Apr 1, 2026

Do I change my PR to a try ... except ?

@cgoldberg
Copy link
Copy Markdown

Do I change my PR to a try ... except ?

yes, or else it will break on older versions of Mypy

@cgoldberg
Copy link
Copy Markdown

@chdemko this looks like a nicer option, and should work for old and new versions: #372 (comment)

@cgoldberg
Copy link
Copy Markdown

@chdemko if this works, it's probably better than setting the attribute directly on opt: #372 (comment)

dosisod added a commit that referenced this pull request Apr 2, 2026
@dosisod dosisod mentioned this pull request Apr 2, 2026
@dosisod dosisod closed this in #375 Apr 2, 2026
@dosisod
Copy link
Copy Markdown
Owner

dosisod commented Apr 2, 2026

Sorry @chdemko , I went down the --allow-redefinitions route to avoid the headache of using the internal class directly.

sthagen pushed a commit to sthagen/dosisod-refurb that referenced this pull request Apr 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: Mypy v1.20.0 breaks refurb

3 participants