Title: frozen packages set an improper __path__ value
Type: behavior Stage: commit review
Components: Interpreter Core Versions: Python 3.0, Python 2.6, Python 2.5
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: benjamin.peterson, brett.cannon, gvanrossum, ncoghlan
Priority: release blocker Keywords: needs review, patch

Created on 2008-10-27 02:42 by brett.cannon, last changed 2008-11-05 22:48 by benjamin.peterson. This issue is now closed.

File name Uploaded Description Edit
issue4211.diff brett.cannon, 2008-10-31 22:54
Messages (6)
msg75250 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2008-10-27 02:42
If you import a frozen package (e.g. __phello__), __path__ is set to
'__phello__'. But this should be a list as specified by both PEP 302
( and the original doc
outlining the package mechanism

Changing import to put the string in a list is all that is needed to
correct this (although it might break some code relying on the fact that
it has been a string in previous versions).
msg75269 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2008-10-27 23:54
Looking at Python/import.c:find_module, fixing this will require
changing the setting of __path__ for frozen packages and how frozen
modules are found. The former will require changing
PyImport_ImportFrozenModule() to use a list instead of a string for the

To make the change work for find frozen modules, find_module() will need
to change. Basically the special-casing for 'path' around frozen module
just needs to go. This will lead to a slight performance penalty as all
imports will require checking for an equivalent frozen module, but since
it is a strcmp in a loop it should not be too bad.

The performance cost can go away if some strapping young lad happens to
re-implement import in such a way that the frozen module parts can
easily be left out. =)

Setting as a release blocker for now in case Barry is willing to let
this go into 3.0rc4.
msg75432 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2008-10-31 22:54
I have an attached patch that fixes the reported problem.

First, it adds a sanity check that no empty module name is checked for
(crashes the interpreter otherwise).

Second, the __path__ attribute is now a list. This does break
backwards-compatibility and thus cannot be backported to 2.6.

Third, I removed the special-casing of frozen packages and just made
frozen module checks a universal thing. This did change the module
resolution order such that frozen modules are checked before built-in
modules and registered modules under Windows (whatever those are).
Moving frozen modules after those two cases are possible if it's really

At this point I need a review to get this into 3.0 and a decision on
whether to backport to 2.7 (I say don't bother, out of
backward-compatibility, but it probably wouldn't really hurt anything
msg75531 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2008-11-05 21:07
FWIW, I agree with the idea of fixing it for 3.0 and leaving it in for 2.x.
msg75532 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2008-11-05 21:30
I approve of the API change. It's 3.0, dammit!
msg75533 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-11-05 22:48
Fixed in r67112.
Date User Action Args
2008-11-05 22:48:44benjamin.petersonsetstatus: open -> closed
nosy: + benjamin.peterson
resolution: accepted -> fixed
messages: + msg75533
2008-11-05 21:30:07gvanrossumsetnosy: + gvanrossum
resolution: accepted
messages: + msg75532
2008-11-05 21:07:26ncoghlansetnosy: + ncoghlan
messages: + msg75531
2008-11-03 22:06:03brett.cannonsetstage: commit review
2008-10-31 22:54:15brett.cannonsetkeywords: + patch, needs review
assignee: brett.cannon ->
messages: + msg75432
files: + issue4211.diff
2008-10-27 23:54:49brett.cannonsetpriority: release blocker
assignee: brett.cannon
messages: + msg75269
2008-10-27 02:42:04brett.cannoncreate