Page MenuHome

Erro in get_type_hints when registering text as module (bug in Python, fix pending)
Closed, ResolvedPublic

Description

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: Intel(R) Iris(R) Plus Graphics Intel 4.5.0 - Build 27.20.100.8681

Blender Version
Broken: version: 2.93.0, branch: master, commit date: 2021-06-02 11:21, hash: rB84da05a8b806
Worked: 2.92

Short description of error
When using the as_module function on a script and running register blender throws an error:

Exact steps for others to reproduce the error


Run the two commands specified in the text file to get the module and register it. I modified the Simple Operator template to make it as simple as possible.

This worked for me in 2.92 for registering and unregistering generated addons dynamically. While it still seems to register in 2.93 operators throw this error. They do appear to be registered when you use them in buttons for example but the property ('test' in the example file) isn't found.

Event Timeline

Richard Antalik (ISS) changed the task status from Needs Triage to Confirmed.Jun 9 2021, 11:31 AM
Will (WCN) added a comment.EditedJun 21 2021, 5:30 AM

For the other users in this thread:

I think I've managed to patch this issue out of my Blender, by going to 2.93/python/lib/python3.9/typing.py in my Blender install directory and changing the one line below.

Change line 1408 from:

base_globals = sys.modules[base.__module__].__dict__

to

base_globals = getattr(sys.modules.get(base.__module__, None), '__dict__', {})

This doesn't seem to have any side effects, and I don't think it really should have any side effects, as it should only modify the code path in conditions where it would otherwise result in an error.


On Blender source code itself:

I think passing an empty dictionary for globalsn to typing.get_type_hints(cls, globalsn={}) in Blender may be enough to get the previous behaviour:

https://docs.python.org/release/3.9.5/whatsnew/changelog.html#id272

It seems to work for getting annotations from the class in the console panel, anyway.

I'm not sure the change upstream is actually going to fix this either. It looks like the new default behaviour is that classes defined in a synthetic module will just be skipped, and not have their annotations collected at all:

https://github.com/python/cpython/pull/25352/files#diff-ddb987fca5f5df0c9a2f5521ed687919d70bb3d64eaeb8021f98833a2a716887

So it may be necessary to pass an empty dict for globalsn even after the upstream fix.


Found the commit where the change was introduced:

https://github.com/python/cpython/commit/f350a268a7071ce7d7a5bb86a9b1229782d4963b#diff-ddb987fca5f5df0c9a2f5521ed687919d70bb3d64eaeb8021f98833a2a716887R1501

Will (WCN) added a comment.EditedJun 21 2021, 3:57 PM

I opened an issue upstream, for the Python standard library:

https://bugs.python.org/issue44468

If they decide to make the new change suggested, then I think that should also fix this issue.

Maybe it'd still be better to explicitly pass an empty dict though, to avoid relying on opaque behaviour.

Campbell Barton (campbellbarton) renamed this task from Erro in get_type_hints when registering text as module to Erro in get_type_hints when registering text as module (bug in Python, fix pending).Jun 23 2021, 9:29 AM
Campbell Barton (campbellbarton) moved this task from Backlog to Known Issues on the Python API board.

I submitted a fix upstream, which has now been merged:

https://github.com/python/cpython/pull/26862

It's been backported to the 3.10 branch, so I guess it will make it into the next release.

Still in Python 3.9.6. There doesn't seem to be any backport for version numbers below 3.10.

Just curious: What is the first version of Blender planned to ship with Python 3.10? (Until then I will have to manually patch the static program files.)

Is there any update on this? I guess this is fixed with python 3.10 to get back to Will's question of when this version will be in blender?

Hi, I also need this for my code (and have needed to patch the program files since this summer (typing.py) to fix this). Would appreciate any update on when it will be implemented or how to fix my current issue.

def import_python_module_absolute_path(path):

"""
Import python file at absolute path.
"""
if os.path.exists(path):
    spec = importlib_util.spec_from_file_location('module', path)
    foo = importlib.util.module_from_spec(spec)
    spec.loader.exec_module(foo)
    return foo
else:
    return None

I am thinking my function here is the culprit, but unsure how I need to change it to bypass this issue. Any help very much appreciated. Thanks :)

Additional note: It's when I try to register this created class with bpy.utils.register_class(foo) that I get the error, which didn't happen before Blender switched python version sometime in late 2020 or early 2021.

Will (WCN) added a comment.EditedJan 29 2022, 10:46 PM

@Marc-Andre Voyer (ispaure) The SVN files for Blender 3.1 have a patched Python 3.10 version in them, so hopefully that will bring the fix to more users.

https://svn.blender.org/svnroot/bf-blender/tags/blender-3.1-release/lib/win64_vc15/python/
https://svn.blender.org/svnroot/bf-blender/tags/blender-3.1-release/lib/win64_vc15/python/310/lib/typing.py

IIRC the problem is a result of synthetic modules: When a module is constructed from a string, file, or some such instead of the usual import mechanisms, the classes in it don't have a .__module__ attribute valid for sys.modules[], so Python 3.9 skips evaluating their type hints for subclasses.

I suppose if you want to "fix" that function, you would probably look into filling in .__module__ in the classes and sys.modules with a synthetic module name:

E.G.:

modulename = f"FakeModule-{path}"
for obj in foo.__dict__.values();
	if isinstance(obj, type) or hasattr(obj, '__module__'):
		obj.__module__ = modulename
		# Also recurse for nesteds if needed.
		# Hm… May AttributeError if you have any slots-y, immutable, or built-in classes in the module top level. Just wrap in a "try" if so.
sys.modules[modulename] = foo
foo.__name__ = modulename #  Not needed, but may as well be thorough.
return foo

Not sure if this the above will be enough. It's been a while since I've looked at this.

Personally I haven't run into this issue since 3.0, though I think that's because my OS's Blender package links to system Python3.10.

This is no longer a problem for Python 3.10 & Blender 3.1, closing.