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
__import__ now raises with non-existing items in fromlist in 3.3 #59920
Comments
This came up while trying to build pygobject with Python 3.3. The problem is there are some erroneous imports in the fromlist with these bindings that can easily be fixed. But it is a behavioral change so I just wanted to raise awareness if it is not already known. $ python3.2 -c "__import__('http', fromlist=['blah'])"
(works) $ python3.3 -c "__import__('http', fromlist=['blah'])"
Traceback (most recent call last):
File "<string>", line 1, in <module>
ImportError: No module named 'http.blah' Note this is also the case when using the C API: PyImport_ImportModuleEx |
While this is a regression, 3.3 definitely puts an increased emphasis on using importlib.import_module() instead of builtins.__import__(). Any reason why import_module() isn't used? As to the regression, while the current behavior makes more sense, it is contrary to a common idiom when using __import__(). However, given the push away from using __import__(), perhaps it can just stay this way. Oh backward compatibility... |
I think pygobject still supports Python 2.5 which it look like importlib is available. I've submitted a patch to pygobject which will work regardless of if this regression is fixed or not: https://bugzilla.gnome.org/show_bug.cgi?id=682051 |
Should have been "...Python 2.5 which it looks like importlib is NOT available." |
Unless it is difficult to fix, I think this regression should be addressed before 3.3 final. Georg? |
The failure output with -v: ...
# /home/esnow/projects/cpython/Lib/http/__pycache__/__init__.cpython-33.pyc matches /home/esnow/projects/cpython/Lib/http/__init__.py
# code object from /home/esnow/projects/cpython/Lib/http/__pycache__/__init__.cpython-33.pyc
import 'http' # <_frozen_importlib.SourceFileLoader object at 0x7ff82770d450>
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "<frozen importlib._bootstrap>", line 1578, in _handle_fromlist
File "<frozen importlib._bootstrap>", line 310, in _call_with_frames_removed
File "<frozen importlib._bootstrap>", line 1530, in _find_and_load
File "<frozen importlib._bootstrap>", line 1494, in _find_and_load_unlocked
ImportError: No module named 'http.blah'
... |
Here's a simple patch the allows bogus names in the fromlist. I'm going to verify that this matches the 3.2 semantics, which may not be so cut-and-dry. |
The following seems to indicate that an ImportError should be raised as expected. I'm guessing that somewhere along the line the exception gets silently eaten. ------------------ (3.2) Python/import.c:ensure_fromlist() [1] submod = import_submodule(mod, subname, buf);
Py_DECREF(item8);
Py_XDECREF(submod);
if (submod == NULL) {
Py_DECREF(item);
return 0;
} [1] http://hg.python.org/cpython/file/3.2/Python/import.c#l2875 |
I agree that we should match 3.2 behavior here. |
And this is why we have said people should use the idiom of Eric's patch looks fine, so I will get it committed today. |
New changeset 0d52f125dd32 by Brett Cannon in branch 'default': |
When people want to import modules with "runtime" names, they regrettably turn to __import__() and likely will for a while. What a source of headaches! If it were less convenient to use __import__(), perhaps fewer people would use it. Could we remove it from <module>.__builtins__, so that it would not be found during the lookup chain? We could still expose it in the builtins module or move it to imp. |
We might be able to hide it in Python 3 since importlib.import_module() has been available since Python 3.1 (and 3.0 is dead anyway). |
I've taken the tanget over to bpo-15720. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: