[Python-Dev] Draft PEP: "Simplified Package Layout and Partitioning"

[Jeff Hardy]

On Tue, Jul 19, 2011 at 8:58 PM, P.J. Eby <pje at telecommunity.com> wrote:
> The biggest likely exception to the above would be when a piece of
> code tries to check whether some package is installed by importing
> it.  If this is done *only* by importing a top-level module (i.e., not
> checking for a ``__version__`` or some other attribute), *and* there
> is a directory of the same name as the sought-for package on
> ``sys.path`` somewhere, *and* the package is not actually installed,
> then such code could *perhaps* be fooled into thinking a package is
> installed that really isn't.

This part worries me slightly. Imagine a program as such:

datagen.py
json/foo.js
json/bar.js

datagen.py uses the files in json/ to generate sample data for a
database. In datagen.py is the following code:

try:
    import json
except ImportError:
    import simplejson as json

Currently, this works just fine, but if will break (as I understand
it) under the PEP because the json directory will become a virtual
package and no ImportError will be raised. Is there a mitigation for
this in the PEP that I've missed?

> However, even in the rare case where all these conditions line up to
> happen at once, the failure is more likely to be annoying than
> damaging.  In most cases, after all, the code will simply fail a
> little later on, when it actually tries to DO something with the
> imported (but empty) module.  (And code that checks ``__version__``
> attributes or for the presence of some desired function, class, or
> module in the package will not see a false positive result in the
> first place.)

It may only be annoying, but it's still a breaking change, and a
subtle one at that. Checking __version__ is of course possible, but
it's never been necessary before, so it's unlikely there's much code
that does it. It also makes the fallback code significantly less neat.

- Jeff