Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

version 0.930 regression: INTERNAL ERROR AttributeError: attribute 'arguments' of 'FuncDef' undefined #11899

Closed
arielf opened this issue Jan 4, 2022 · 12 comments
Labels

Comments

@arielf
Copy link

arielf commented Jan 4, 2022

Just sharing a regression I just hit on code that used to pass mypy before.

Unfortunately, updating from git is not an option in my env.

Line 273 in source I can't fully share is the first (def) line below which is one (override) method in a big class:

    def update(self,  # type: ignore
               name: Optional[str] = None,
               description: Optional[str] = None,
               metric: Optional[SyntheticObject] = None,
               category: Optional[UserDefinedObjectRequestcategoryEnum] = None,
               cacherefreshseconds: Optional[int] = None,
               refreshDataType: Optional[bool] = None,
               properties: Optional[ColumnParamsR] = None,
               keyEntity: Optional[str] = None,
               dataType: Optional[SomePrivateDataType] = None,
               initialCollection: Optional[str] = None) -> EntityProperty:

Stack trace when running mypy is:

.../entityproperty.py:273: error: INTERNAL ERROR -- Please try using mypy master on Github:
https://mypy.readthedocs.io/en/stable/common_issues.html#using-a-development-mypy-build
Please report a bug at https://github.com/python/mypy/issues
version: 0.930
Traceback (most recent call last):
  File "/usr/lib/python3.8/runpy.py", line 194, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.8/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "mypy/checker.py", line 420, in accept
  File "mypy/nodes.py", line 727, in accept
  File "mypy/checker.py", line 770, in visit_func_def
  File "mypy/checker.py", line 781, in _visit_func_def
  File "mypy/checker.py", line 1469, in check_method_override
  File "mypy/checker.py", line 1497, in check_method_or_accessor_override_for_base
  File "mypy/checker.py", line 1583, in check_method_override_for_base_with_name
  File "mypy/checker.py", line 1745, in check_override
  File "mypy/messages.py", line 839, in signature_incompatible_with_supertype
  File "mypy/messages.py", line 861, in pretty_callable_or_overload
  File "mypy/messages.py", line 1937, in pretty_callable
AttributeError: attribute 'arguments' of 'FuncDef' undefined
.../entityproperty.py:273: : note: use --pdb to drop into pdb
@A5rocks
Copy link
Contributor

A5rocks commented Jan 5, 2022

Looks to me like it's saying your class has a method (I assume this update method?) which is incompatible with the class it is inheriting from. And then, when it tries to print the superclass method, it... the superclass method isn't fully cached or something?

Not sure -- does clearing the cache fix this?

@arielf
Copy link
Author

arielf commented Jan 5, 2022

Thank you so much!

Confirming. Both of the below solutions worked for me:

  1. Downgrade to mypy-0.920 while keeping the existing mypy cache
python3 -m pip install --user mypy==0.920
  1. Upgrade back to mypy-0.930 AND clear the mypy cache:
python3 -m pip install --user mypy==0.930

rm -rf .mypy_cache

Thanks again. This comment was very helpful.

@arielf
Copy link
Author

arielf commented Jan 5, 2022

Sorry I have to take workaround (2) above back.

It solved the issue only for the 1st run (empty cache)

If I rerun mypy, even on a fresh cache (created by mypy-0.930) I get the INTERNAL ERROR again.

so the only real workaroud is (1) above: downgrade back to mypy-0.920

@hauntsaninja

This comment has been minimized.

@hauntsaninja
Copy link
Collaborator

Okay, not fully minimal, but I think at least the following should get you a crash:

python -m pip install 'mypy==0.930' 'ray[default]==1.9.1' 'transformers==4.15.0' 'pytorch_lightning==1.5.3'
python -m mypy -c 'import ray; reveal_type((ray.get, ray.init, ray.remote))' --show-traceback --ignore-missing-imports --check-untyped-defs

@A5rocks
Copy link
Contributor

A5rocks commented Jan 7, 2022

I think @hauntsaninja's bug is #7045 -- though if it's a 0.930 regression then maybe not. (why'd I remember this? Cause I noticed the transformers install though I doubt that's why :^)

@hauntsaninja
Copy link
Collaborator

hauntsaninja commented Jan 7, 2022

Nice spot! Yeah, that should account for the second stacktrace. The first stacktrace, which is what the repro gives is #10521 and #9081 . It is not a regression since 0.930, I just got fooled by the timing of it popping up in this codebase. Sorry for cluttering up this issue!

@fperrin
Copy link
Contributor

fperrin commented Mar 9, 2022

I believe I have a small repro case for this internal crash:

mkdir app
touch app/__init__.py
cat > app/a.py <<EOF
class Foo:
    def frobnicate(self, *args, **kwargs): pass
EOF

cat > app/b.py <<EOF
from app.a import Foo
class Bar(Foo):
    def frobnicate(self) -> None: pass
EOF

Then run mypy -m app.b twice. The first one will fail with Signature of "frobnicate" incompatible with supertype as expected, the second time triggers an INTERNAL ERROR:

(3.9.4-devtools) fperrin-laptop:/tmp/repro-11899% mypy -m app.b
app/b.py:3: error: Signature of "frobnicate" incompatible with supertype "Foo"
app/b.py:3: note:      Superclass:
app/b.py:3: note:          def frobnicate(self, *args: Any, **kwargs: Any) -> Any
app/b.py:3: note:      Subclass:
app/b.py:3: note:          def frobnicate(self) -> None
Found 1 error in 1 file (checked 1 source file)
zsh: exit 1     mypy -m app.b
(3.9.4-devtools) fperrin-laptop:/tmp/repro-11899% mypy -m app.b
app/b.py:3: error: Signature of "frobnicate" incompatible with supertype "Foo"
app/b.py:3: note:      Superclass:
/private/tmp/repro-11899/app/b.py:3: error: INTERNAL ERROR -- Please try using mypy master on Github:
https://mypy.readthedocs.io/en/stable/common_issues.html#using-a-development-mypy-build
If this issue continues with mypy master, please report a bug at https://github.com/python/mypy/issues
version: 0.950+dev.4a744b35e28277e2193feb78de90d3b3cbb3169b
/private/tmp/repro-11899/app/b.py:3: : note: please use --show-traceback to print a traceback when reporting a bug
zsh: exit 2     mypy -m app.b

I just tried with version: 0.950+dev.4a744b35e28277e2193feb78de90d3b3cbb3169b.

fperrin added a commit to fperrin/mypy that referenced this issue Mar 9, 2022
Minimum reproduction of issue python#11899. The second iteration of that
incremental test fails with:

b.py:3: error: INTERNAL ERROR -- Please try using mypy master on Github:
[ ... ]
Dropping into pdb
> mypy/messages.py(1951)pretty_callable()
-> definition_args = [arg.variable.name for arg in tp.definition.arguments]
(Pdb) p type(tp.definition)
<class 'mypy.nodes.FuncDef'>
(Pdb) p tp.definition.arguments
*** AttributeError: arguments
fperrin added a commit to fperrin/mypy that referenced this issue Mar 9, 2022
fperrin added a commit to fperrin/mypy that referenced this issue Mar 22, 2022
When FuncDef is deserialized we don't reconstruct the arguments.
Previous code was deleting the attribute, leading to python#11899; instead,
always set the attribute, maybe to None, and mypy can remind us to
check for not None before use.
fperrin added a commit to fperrin/mypy that referenced this issue Mar 22, 2022
When FuncDef is deserialized we don't reconstruct the arguments.
Previous code was deleting the attribute, leading to python#11899; instead,
always set the attribute, maybe to None, and mypy can remind us to
check for not None before use.
fperrin added a commit to fperrin/mypy that referenced this issue May 12, 2022
When FuncDef is deserialized we don't reconstruct the arguments.
Previous code was deleting the attribute, leading to python#11899; instead,
always set the attribute, maybe to None, and mypy can remind us to
check for not None before use.
@KotlinIsland
Copy link
Contributor

KotlinIsland commented May 20, 2022

This looks like a duplicate of #11449

fperrin added a commit to fperrin/mypy that referenced this issue May 20, 2022
When FuncDef is deserialized we don't reconstruct the arguments.
Previous code was deleting the attribute, leading to python#11899; instead,
always set the attribute, maybe to None, and mypy can remind us to
check for not None before use.
fperrin added a commit to fperrin/mypy that referenced this issue May 20, 2022
When FuncDef is deserialized we don't reconstruct the arguments.
Previous code was deleting the attribute, leading to python#11899; instead,
always set the attribute, maybe to the empty list, and get argument
names from arg_names if arguments is empty.
@fperrin
Copy link
Contributor

fperrin commented May 20, 2022

This looks like a duplicate of #11449

It does indeed. I have a proposed fix in #12324, I need to rebase because after recent changes to mypy master.

fperrin added a commit to fperrin/mypy that referenced this issue May 20, 2022
When FuncDef is deserialized we don't reconstruct the arguments.
Previous code was deleting the attribute, leading to python#11899; instead,
always set the attribute, maybe to the empty list, and get argument
names from arg_names if arguments is empty.
fperrin added a commit to fperrin/mypy that referenced this issue May 20, 2022
When FuncDef is deserialized we don't reconstruct the arguments.
Previous code was deleting the attribute, leading to python#11899; instead,
always set the attribute, maybe to the empty list, and get argument
names from arg_names if arguments is empty.
@AlexWaygood
Copy link
Member

Since we upgraded to mypy 0.960 over at typeshed, I now (for some reason) hit this crash every time I run mypy_test.py twice in a row locally. It's always the exact same traceback as in this issue, and it always occurs when mypy runs on our Flask-SQLAlchemy stubs.

fperrin added a commit to fperrin/mypy that referenced this issue Jun 24, 2022
When FuncDef is deserialized we don't reconstruct the arguments.
Previous code was deleting the attribute, leading to python#11899; instead,
always set the attribute, maybe to the empty list, and get argument
names from arg_names if arguments is empty.
@hauntsaninja
Copy link
Collaborator

Should be fixed by #12324. Let me know if anyone has a repro of bad behaviour against current master. And thanks again to @fperrin for finding a minimal repro and making a fix!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants