Brett Cannon added the comment:
So this is very old semantics from the Python 2 days. I think Nick's idea of
transforming the import to `import pkg.mod` when pkg isn't in sys.modules is
probably the simplest, cleanest solution if we're going to change this.
--
Antoine Pitrou added the comment:
I concur with Serhiy: SystemError is a smell that C code isn't taking
appropriate precautions before dealing with user code or data.
--
nosy: +pitrou
___
Python tracker
Nick Coghlan added the comment:
If there are intermittent concurrent problems associated with this behaviour, I
think that may be a sign that the current management of the per-module import
locks is inadequate, since it isn't adequately accounting for direct
manipulation of sys.modules in
Serhiy Storchaka added the comment:
I don't know other way to provoke SystemError by Python code. Always if
SystemError was leaked this considered a bug and was fixed.
When unload package you need to remove its name and names of its submodules
from sys.modules. This is a common case. If the
Nick Coghlan added the comment:
To summarise what the attached source archive is doing, module1.py is
essentially:
import sys
del sys.modules(__package__)
from . import module2
So the only way to trigger this is by corrupting the import state, which seems
like an appropriate use
Nick Coghlan added the comment:
I don't think we're that strict with SystemError - once folks are messing about
with deleting things from the sys module, they *are* writing their own system
level code, and may end up provoking SystemError if they corrupt the
interpreter state in the process.
New submission from Serhiy Storchaka:
It is possible to get SystemError on import (see attached archive).
$ ./python -c 'import package.module1'
Traceback (most recent call last):
File "", line 1, in
File "/home/serhiy/py/cpython/package/module1.py", line 3, in
from . import module2