zipimporter find_module fullname mis-documented

[kmtracey]

BPO	8400
Nosy	@gpshead, @kmtracey, @cool-RR, @ericsnowcurrently, @serhiy-storchaka, @tirkarthi

^{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 2010-04-14.15:20:40.742>
labels = ['3.8', 'type-bug', '3.7']
title = 'zipimporter find_module fullname mis-documented'
updated_at = <Date 2020-01-24.23:26:31.133>
user = 'https://github.com/kmtracey'

bugs.python.org fields:

activity = <Date 2020-01-24.23:26:31.133>
actor = 'brett.cannon'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2010-04-14.15:20:40.742>
creator = 'kmtracey'
dependencies = []
files = []
hgrepos = []
issue_num = 8400
keywords = []
message_count = 8.0
messages = ['103132', '109467', '134584', '175527', '175565', '175566', '342587', '342665']
nosy_count = 9.0
nosy_names = ['gregory.p.smith', 'kmtracey', 'rfk', 'cool-RR', 'tjd.rodgers', 'eric.snow', 'serhiy.storchaka', 'superluser', 'xtreak']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'test needed'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue8400'
versions = ['Python 3.7', 'Python 3.8']

[kmtracey]

The fullname parameter to zipimporter find_module is documented to be a "fully qualified (dotted) module name". (From http://docs.python.org/library/zipimport.html#zipimport.zipimporter.find_module.) However, passing a fully-qualified dotted module appears to never work. Rather it appears that you must use the file system path separator instead of dots. For example on Windows:

C:\>echo %pythonpath%
\tmp\blah-1.0-py2.6.egg

C:\>python
Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from blah.models import speak
>>> speak.__file__
'C:\\tmp\\blah-1.0-py2.6.egg\\blah\\models\\speak.pyc'
>>> speak.sayhi()
Hi from blah.models.speak sayhi function.

The egg has top-level blah package and under it models, it appears to work fine for normal use. But zipimport zipimporter find_module won't find the models sub-module using dotted path notation:

>>> import sys
>>> sys.path[1]
'C:\\tmp\\blah-1.0-py2.6.egg'
>>> import zipimport
>>> zi = zipimport.zipimporter(sys.path[1])
>>> zi.find_module('blah')
<zipimporter object "C:\tmp\blah-1.0-py2.6.egg">
>>> zi.find_module('blah.models')
>>> zi.find_module('blah/models')
>>> zi.find_module('blah\\models')
<zipimporter object "C:\tmp\blah-1.0-py2.6.egg">
>>>

On Linux, the 'blah/models' version is the one that works.

Tested as far back as Python2.3 and as far forward as 2.7a3.

[rfk]

Was also just bitten by this, trying to muck with PEP-302-style import hooks. Note that the documented behaviour of zipimporter is also the behaviour required by PEP-302, i.e. full dotted module name.

[cool-RR]

I was bitten now as well...

[tjdrodgers]

I have also just been bitten by this. Is there anyway that this can be updated to support the dotted notation?

[tjdrodgers]

It gets worse. Even though find_module works with the path separator, load_module fails.

>>> zi.find_module("lib\\ui")
<zipimporter object "dist/Test_Editor-1.0-py3.2.zip">
>>> zi.load_module("lib\\ui")
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "dist/Test_Editor-1.0-py3.2.zip\lib\ui\__init__.py", line 9, in <module>
 File "dist\Test_Editor-1.0-py3.2.zip\lib\ui\texteditorwindow.py", line 5, in <module>
 File "dist\Test_Editor-1.0-py3.2.zip\lib\ui\designer\__init__.py", line 5, in <module>
ValueError: Attempted relative import beyond toplevel package

[tjdrodgers]

Disregard the last...error on my part (so embarrassing!)

[tirkarthi]

This still exists after zipimport rewrite in Python with 3.8 . Is this a documentation issue or an enhancement to be made as noted in msg109467 ?

[brettcannon]

Actually find_module() should be deprecated and find_spec() should be defined instead (and the same goes for load_module(); see bpo-9699). So I'm personally fine w/ making this a doc problem w/ the plan to eventually deprecate the method.

[hugovk]

Closing this as find_module is deprecated since 3.10 and slated for 3.12 removal:

• https://docs.python.org/3/library/zipimport.html#zipimport.zipimporter.find_module
• https://docs.python.org/3/whatsnew/3.10.html#deprecated
• Raise ImportWarning when loader.load_module() is used #70319
• gh-70319: Deprecate usage of load_module() #23469