[Import-SIG] [Python-ideas] My objections to implicit package directories
ericsnowcurrently at gmail.com
Tue Mar 13 21:25:04 CET 2012
On Mon, Mar 12, 2012 at 5:03 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> In large part, the "Why are my imports broken?" section in PEP 395
> exists because I sat down to try to document what does and doesn't
> work when you attempt to directly execute a module from inside a
> package directory. In building the list of what would work properly
> ("python -m" from the parent directory of the package) and what would
> sometimes break (everything else), I realised that instead of
> documenting the entire hairy mess, the 1:1 mapping from the filesystem
> layout to the Python module hierarchy meant we could *just fix it* to
> not do the wrong thing by default. If implicit package directories are
> blessed for inclusion in Python 3.3, that opportunity is lost forever
> - with the loss of the unambiguous 1:1 mapping from the filesystem
> layout to the module hierarchy, it's no longer possible for the
> interpreter to figure out the right thing to do without guessing.
Here's one idea to address the PEP 395 concern.
Traverse up the directory tree until you hit one of the following three markers:
* there is no __init__.py in the current directory (in the case where
there was one adjacent to the original module)
* current directory is on sys.path
* setup.py is in the current directory
All these indicate that you have left the package. If you make it to
the FS root, the module would not be considered to exist in a package.
The third option is the new idea. As a bonus, using setup.py as a
marker would also nudge people toward packaging.
More information about the Import-SIG