[BUG] 🐍 3.10-dev (ubuntu, mac, ~windows): TypeError: 'str' object is not callable

[EricCousineau-TRI]

Seen this crop up in my PR and another:

/home/runner/work/pybind11/pybind11/tests/test_embed/test_interpreter.cpp:244: FAILED:
  {Unknown expression after the reported line}
due to unexpected exception with message:
  TypeError: 'str' object is not callable

Example PRs:

• Add option for enable/disable enum members in docstring. #2768 | https://github.com/pybind/pybind11/pull/2768/checks?check_run_id=1656501003#step:12:36
• Update 'inactive_override_cache' key #2772 | https://github.com/pybind/pybind11/pull/2772/checks?check_run_id=1665608739#step:12:35

Guessing it's just a minor thing that'll blow over. I guess we can close this if we don't see it reoccur?

FYI @henryiii @YannickJadoul

[YannickJadoul]

Already spotted this in #2768 as well, but haven't had time to look closer. We might not want to wait until 3.10 is released to report this (ahem we'd never let such a thing happen cough) ;-)

[henryiii]

Before looking at the code, this looked like something is being passed through as a type annotation and being called, but now type annotations are all strings, so it's now calling a string instead of a callable. But have no clue where anything like that would be in our code. It seems to possibly be happening when a module is being reloaded? That could be an issue somewhere in Python's stdlib code.

I think 3.10a4 is the first with "from __future__ import annotations" on by default, which is also suspicious.

[henryiii]

We don't run these tests on Windows after 3.7 due to the DLL loading changes which we've never worked around, IIRC. So it's likely a problem everywhere.

[EricCousineau-TRI]

We don't run these tests on Windows after 3.7 due to the DLL loading changes which we've never worked around, IIRC. So it's likely a problem everywhere.

Er, I understood your prior post, but I'm not sure how Windows 3.7 w/ DLL relates to 3.10-dev - can you expand on that?

[EricCousineau-TRI]

Oh - meaning I should remove the (ubuntu, mac) specifier. Derp.

[bstaletic]

We don't run these tests on Windows after 3.7 due to the DLL loading changes which we've never worked around, IIRC. So it's likely a problem everywhere.

In 3.8+ loading DLLs on Winblows changes in this way (os.add_dll_directory):

https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-python-api
https://docs.python.org/3/whatsnew/3.8.html#os
https://docs.python.org/3/whatsnew/3.8.html#ctypes
https://docs.python.org/3/library/os.html?highlight=add_dll_directory#os.add_dll_directory

Here's add_dll_directory used in my project: ycm-core/ycmd@6c28224

@henryiii tried to fix this for pybind11, but with no success.

[bstaletic]

this looked like something is being passed through as a type annotation and being called, but now type annotations are all strings

That would mean this would be reproducible on python 3.9.1 with from __future__ import annotations. I tried adding that line to all tests/**/test_*.py files, but make cpptest was successful

[YannickJadoul]

I just tried, but I can't reproduce locally with the last version of Python. I installed "Python 3.10.0a4+ (heads/master:d16f617, Jan 9 2021, 20:40:43)" through pyenv, and all tests pass. I'll give the exact same version, 3.10.0a4, a try as well.

[YannickJadoul]

I just tried, but I can't reproduce locally with the last version of Python. I installed "Python 3.10.0a4+ (heads/master:d16f617, Jan 9 2021, 20:40:43)" through pyenv, and all tests pass. I'll give the exact same version, 3.10.0a4, a try as well.

Scratch that. It's the embedding tests that fail. If you run those, CPython's master still fails.

[henryiii]

I suspect it's loading a file somewhere in Python, not our .py's. We don't use annotations, sadly, much less try to call them.

[henryiii]

Is there some way to get more information about where the failure actually is, perhaps? If we just had a filename, that would be huge. We need from rich.traceback import install; install(show_locals=True) , perhaps :)

[YannickJadoul]

Seems like something worse is going on, though, I'm afraid. If I comment out preceding tests in test_interpreter.cpp, I'm getting a beautiful SIGABRT:

Fatal Python error: compiler_make_closure: lookup '__class__' in DerivedWidget 5 -1
freevars of __init__: ('__class__',)