Open klausweiss opened 1 year ago
I've identified that v1.0.0+dev.f37a0aeeb89b87de2d2bcdb7a749e4e6f63a3185 was the first build that introduced the issue.
Was able to reproduce it with locally-built wheels - cloned mypy locally, checkedout the commit that's of my interest and installed mypy from the local directory in the venv from above, having set the MYPY_USE_MYPYC="1"
environment variable.
This allowed me to identify the commit that introduced the regression: https://github.com/python/mypy/commit/28e5436bbba16c8a217dace56b951898e53532f9
This might break some plugins, so we should document this in release notes and the relevant issue that tracks plugin incompatibilities.
👋
I can see it was announced (https://github.com/python/mypy/issues/6617#issuecomment-1381743984), but never would have thought it could affect my plugin. Subscribed to the Announcement issue just now. Time to dive into the mypy internals to understand why it was affected, I guess.
Thanks for narrowing that down 🤔 mypyc must be miscompiling something to do with IncomparableTypeName
@JukkaL do you have any suspicious for why mypyc-compiled mypy is different from interpreted mypy with this plugin?
These are some things that could cause issues in plugins:
str
(or a few other builtin types)TypeError
or ValueError
Each of these could plausibly generate issues when running compiled mypy. I notice that the plugin actually does inherit from str
(IncomparableTypeName
). This is the likely reason why things go wrong. Previously the type of fullname
was Any
when compiling so no specialized str
primitives could be used by mypyc
. Now str
primitives are used, and these apparently don't support str
subclassing properly. In particular, overriding __eq__
does not seem to be supported.
We should either document the incompatibility (if it's undocumented) or fix it. Fixing it will probably have a slight performance penalty, but it may well be worth it, as deviations such as these are surprising and hard to debug.
Hello,
I noticed that the
manylinux_2_17_x86_64.manylinux2014_x86_64
andpy3-none-any
pypi wheels behave differently.Bug Report
...but I don't know specifically what the issue is 😬 I wrote a mypy plugin. It used to work correctly with mypy 0.920-0.991. Then the tests started failing in CI when 1.0.0 was released. I've easily reproduced that locally. Wanted to get to the bottom of it, so downloaded mypy source, checked out v1.0.0, installed the local package and... the tests passed. I've only later discovered that when I use the
py3-none-any
wheel from pypi it also works as expected.The plugin hooks into
get_type_analyze_hook
,get_method_signature_hook
andget_function_signature_hook
modifying instances of a specific class (joining Protocols together). I understand this is no place to seek help in my project, but I believe the issue is with these particular distributions and not on my end, since everything works correctly when using the source or the generic wheel.Locally I'm testing everything with python 3.10.9, but I've also confirmed this is the case with 3.11.1 and it failed with 3.7.15 in CI (Github Actions).
To Reproduce
I wish I could provide a simpler example, but I'm afraid I can't. I've tried narrowing the issue down, but couldn't do it with a compiled version of mypy and the source version works beautifully 😬 .
Outcome is
Expected Behavior
Outcome:
You get the expected outcome when you follow the same steps as above, but downloading a
py3-any-none
wheel instead:Again, that's also the behavior I observed when cloning the mypy repo, checking out v1.0.0, and installing from a local directory.
Actual Behavior
See the To Reproduce section.
Your Environment
v1.0.0
--no-incremental --config-file tests/test-mypy.ini
mypy.ini
(and other config files):tests/test-mypy.ini
:3.10.9
but also with3.11.1
and3.7.15
, haven't checked any others