You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Refurb is a project that depends on Mypy internals to work properly. Since v1.7.0 of Mypy (specifically since #15770 was merged), Refurb no longer works, and instead emits the following error:
$ refurb file.py
interpreted classes cannot inherit from compiled traits
I tried a bunch of different workarounds including making a custom __new__ method, copy-and-pasting TraverserVisitor into my code and removing the @trait, but alas nothing is working, and so I had to pin Mypy to <= v1.6.1 in Refurb, which will prevent users from using the newest version of Mypy with Refurb. Using the non-compiled version of Mypy doesn't have this issue, but doing so would be far too slow, especially since Refurb parses/walks the full, fine-grained AST tree (similar to mypyd).
My question: How should I get around this? Is there anything I can do on my end, or does something in Mypy have to change? I would think that allow_interpreted_subclasses=True would nullify the inheritance restriction imposed by @trait, but that doesn't seem to be the case.
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.
The text was updated successfully, but these errors were encountered:
I would think that allow_interpreted_subclasses=True would nullify the inheritance restriction imposed by @trait, but that doesn't seem to be the case.
I definitely remember we wanted to allow this, but probably this is still not done. Anyway, an idea worth trying is to move @trait from TraverserVisitor to BaseStubGenerator. I guess there are more people who want to inherit from the former, while the latter is quite niche.
Bug Report
Refurb is a project that depends on Mypy internals to work properly. Since v1.7.0 of Mypy (specifically since #15770 was merged), Refurb no longer works, and instead emits the following error:
See also: dosisod/refurb#305
To Reproduce
Expected Behavior
Refurb doesn't crash.
Actual Behavior
Refurb is crashing.
Your Environment
Background
#15770 added a
@trait
decorator toTraverserVisitor
, meaning 3rd party (interpreted) programs can no longer inherit fromTraverserVisitor
:mypy/mypy/traverser.py
Lines 97 to 99 in c6cb3c6
I tried a bunch of different workarounds including making a custom
__new__
method, copy-and-pastingTraverserVisitor
into my code and removing the@trait
, but alas nothing is working, and so I had to pin Mypy to <= v1.6.1 in Refurb, which will prevent users from using the newest version of Mypy with Refurb. Using the non-compiled version of Mypy doesn't have this issue, but doing so would be far too slow, especially since Refurb parses/walks the full, fine-grained AST tree (similar to mypyd).My question: How should I get around this? Is there anything I can do on my end, or does something in Mypy have to change? I would think that
allow_interpreted_subclasses=True
would nullify the inheritance restriction imposed by@trait
, but that doesn't seem to be the case.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.
The text was updated successfully, but these errors were encountered: