Repository navigation
Allow built-in packages and submodules as well as top-level modules #44508
Description
| BPO | 1644818 |
|---|---|
| Nosy | @loewis, @freddrake, @brettcannon, @terryjreedy, @ncoghlan, @vstinner, @encukou, @jd, @ericsnowcurrently |
| Files |
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:
assignee = None
closed_at = None
created_at = <Date 2007-01-25.22:12:30.000>
labels = ['interpreter-core', 'type-feature']
title = 'Allow built-in packages and submodules as well as top-level modules'
updated_at = <Date 2018-05-02.12:19:24.718>
user = 'https://bugs.python.org/mlobo'bugs.python.org fields:
activity = <Date 2018-05-02.12:19:24.718>
actor = 'fdrake'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2007-01-25.22:12:30.000>
creator = 'mlobo'
dependencies = []
files = ['7739', '7740', '7741', '17126']
hgrepos = []
issue_num = 1644818
keywords = ['patch']
message_count = 14.0
messages = ['51802', '51803', '51804', '51805', '51806', '51807', '96588', '96590', '104436', '104506', '104507', '113445', '113471', '252374']
nosy_count = 12.0
nosy_names = ['loewis', 'fdrake', 'brett.cannon', 'collinwinter', 'terry.reedy', 'ncoghlan', 'vstinner', 'mlobo', 'Arfrever', 'petr.viktorin', 'jd', 'eric.snow']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue1644818'
versions = ['Python 3.4']
Activity
mlobo commentedon Jan 25, 2007
At the moment importing built-in submodules (in my case PyQt4.QtCore and PyQt4.QtGui) does not work. This seems to be because find_module in import.c checks only the module name (e.g. QtCore) against the built-in list, which should contain the full name (e.g. Python.QtCore) instead.
Also, the above check is performed after the code to check if the parent module is frozen, which would have already exited in that case.
By moving the is_builtin() check to earlier in find_module and using fullname instead of name, I can build PyQt4.QtCore and PyQt4.QtGui into the interpreter and import and use them with no problem whatsoever, even if their parent module (PyQt4) is frozen.
I have run the regression tests and everything seems Ok.
I am completely new to CPython development so it is quite possible that my solution is undesirable or that I have done something incorrectly. Please let me know if that is the case.
Finally, the attached patch is for Python-2.5, but I have checked it also applies to current svn trunk with only a one-line offset.
collinwinter commentedon Mar 6, 2007
This is the kind of thing you should bring up on the python-dev list (http://mail.python.org/mailman/listinfo/python-dev). Please subscribe to the list and send in a post with your problem and proposed solution. Thanks for your effort!
loewis commentedon Mar 6, 2007
Can you come up with a test case? Put the module in Modules/Setup, then have a test case that tries importing it. The test case should check whether the module is in builtin_module_names, and, if it is, try importing it.
(Ideally, it should only make the module builtin if debug is enabled, but I can't see how that can be achieved. Perhaps some trickery in config.c could do that, and #ifdefing out the body of the module if debug is disabled).
mlobo commentedon Mar 6, 2007
Ok, I have added a test case and it has actually allowed me to fix a small bug: I had tested the case where the parent of the submodule is a normal Python module and the case where it is a frozen module, but another small fix was needed to make it work if the parent is built-in itself.
Please be aware that I have only run the regression tests under Windows, as at the moment I don't have a suitable Unix box available.
Also, I have uploaded the test case file (test_submodule.py) separately, as I don't know how to convince SVN to put this file in the patch.
The new patch is against current trunk.
File Added: import.diff
mlobo commentedon Mar 6, 2007
File Added: test_submodule.py
mlobo commentedon Mar 6, 2007
Argh, I've just realized I forgot to upload the built-in submodule itself. This obviously goes in Modules.
File Added: xxsubmoduletest.c
11 remaining items
[-]Allow importing built-in submodules[/-][+]Allow built-in packages and submodules as well as top-level modules[/+][-]Allow importing built-in submodules[/-][+]Allow built-in packages and submodules as well as top-level modules[/+]ncoghlan commentedon Apr 29, 2010
Unassigning - this idea needs a lot more specification work to be done before actually implementing it becomes a good idea.
(e.g. IronPython and Jython should be looked at to see how they handle the naming schemes in the standard libraries for their respective runtime environments)
terryjreedy commentedon Aug 9, 2010
I believe this is covered by the PEP-3003 3.2 change moratorium.
brettcannon commentedon Aug 9, 2010
Import is explicitly exempt from the moratorium. But since the moratorium expires starting with Python 3.3 it really doesn't matter since this change will not go into 3.2.
ncoghlan commentedon Oct 6, 2015
Petr, this could be an interesting issue to take a look at from the point of view of the builtin and extension module import changes in Python 3.5.
Given the extent of the import system changes across 3.3/4/5, it's even conceivable we may have made this work somewhere along the line. In that case we'd still need a new regression test to ensure it keeps working - we didn't even have a regression test to ensure extension module imports from inside a package worked, so we definitely don't have one for builtin submodules.