[Python-Dev] Dropping __init__.py requirement for subpackages

[Delaney, Timothy (Tim)]

Guido van Rossum wrote:

> The difference is that if you find a valid module package later on the
> path, you'll still get warnings.

This is the bit I don't like about it. Currently the warnings are
displayed as the packages are found. I'd be quite happy with the
warnings if they were suppressed until there is an actual ImportError -
at which time they'll be displayed.

> But occasionally those will be useful
> too -- when you are trying to create a package that happens to have
> the same name as a standard library package or module, it's a lot
> easier to debug the missing __init__.py if you get a warning about it
> instead of having to figure out that the foo you imported is not the
> foo you intended.

I suspect that more often any warnings when there is a successful import
will be spurious. But testing in the field will reveal that. So I say
alpha 3 should have Thomas' patch as is, and it can be changed
afterwards if necessary.

> Thomas' patch does this automatically -- you get a warning for each
> directory that is weighed and found too light.

Not exactly - you'll get warnings for directories earlier in sys.path
than a matching package. Potential packages later in the path won't be
warned about. If you're trying to resolve import problems, it's just as
likely that the package you really want is later in sys.path than
earlier. Obviously in the case that you get an ImportError this goes
away.

> Is it also useful to distinguish a subpackage from a non-subpackage?

Possibly. Perhaps it would be useful to have `is_package(dirname)`,
`is_rootpackage(dirname)` and `is_subpackage(dirname)` functions
somewhere (pkgutils?). Then the tools objections go away, and whatever
mechanism is necessary to determine this (e.g. is_rootpackage checks if
the directory is importable via sys.path) can be implemented.

> Anyway, the warning is more compatible and just as helpful so we'll go
> with that.

Fair enough.

Tim Delaney