Éric Araujo added the comment:
I knew that a package would win over a module, but an initless package does
not? Yuck :(
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17108
R. David Murray added the comment:
It has to be that way to preserve backward compatibility, since IIUC before the
PEP there was no such thing as an initless package, it was just a directory
that was ignored by import.
--
___
Python tracker
Eric Snow added the comment:
Deprecating pkg/__init__.py and having pkg.py coexist with pkg/ was on the
table in an earlier proposal (PEP 402). In that case pkg/__init__.py would
have been tried first for backward compatbility (until eliminated in Python 4
or whenever). PEP 420 (namespace
Terry J. Reedy added the comment:
I looked through both the old 2.7 import statement doc and the new 3.3 import
statement doc and import system chapter (5. The import system) and could not
find anything about what a Path Based Finder path entry finder does when a
particular path entry has
R. David Murray added the comment:
Ah, yes.
To clarify for Shai, by the way, the reason this stuff can't change (and the
reason there is a new step 3 instead of changing the whole algorithm to be
something more sensible) is because of the requirement of maintaining backward
compatibility.
Shai Berger added the comment:
Hi,
the reason this stuff can't change [... is] backward compatibility.
Thanks, but this is still unclear to me. The required fix for code that would
break because of the change I propose, is removal of dead code which looks
misleadingly alive.
Is the
R. David Murray added the comment:
Yes. Imagine you have a deployed application, and there happens to be an xx.py
file that is masked by a package in it. You upgrade from pythonX.Y.Z to
X.Y.Z+1, and your application is suddenly throwing an error. Yes it is easy to
fix, but we prefer not to
Shai Berger added the comment:
Oh, sure, this was unclear of me. I thought you were talking about Python 3.4.
I wasn't really expecting this to be fixed in the stable branches.
Thanks,
Shai.
--
___
Python tracker rep...@bugs.python.org
New submission from Shai Berger:
Consider the following directory structure:
a-\
__init__.py
b.py
b-|
__init__.py
Now, in Python (I checked 2.7.3 and 3.2.3, haven't seen the issue mentioned
anywhere so I suspect it is also in later Pythons), if you import a.b, you
always get the
R. David Murray added the comment:
This is behavior has been true since packages were introduced, and is not going
to change. However, I agree that it could be better documented.
In Python3 something that needs to do dynamic module discovery can use
importlib to be sure of using the same
Shai Berger added the comment:
Thanks for the quick response.
If this isn't changing, I'd definitely want better documentation. In
particular, the rationale behind this should be explained.
I submitted the bug because a co-worker unintentionally caused a whole suite of
tests to be ignored.
Eric Snow added the comment:
Other than the language reference (with its updated info on imports--thanks
Barry!), what other documentation would benefit from a note on this? Somwhere
in http://docs.python.org/dev/tutorial/modules.html?
--
nosy: +eric.snow
R. David Murray added the comment:
It was mostly the language reference I was thinking of, since that's where I
think one would naturally go to find out about unexpected behavior of the
import statement, but a note in the tutorial is probably not a bad idea. I'm
not sure if this rises to the
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17108
___
Eric Snow added the comment:
By the way,...
Yeah, PEP 420 (implemented in 3.3) introduced namespace packages. The new
behavior you're thinking of is where a package doesn't need a __init__.py. So
path-based lookup for modules, the order goes like this (for import
spam.eggs):
1. look for
15 matches
Mail list logo
