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

[Guido van Rossum]

On 4/26/06, Delaney, Timothy (Tim) <tdelaney at avaya.com> wrote:
> I really think it would be more useful having an ImportError containing
> a suggestion than having a warning. Anyone who knows it's bogus can just
> ignore it.

That's effectively what Thomas's patch does though -- if at the end
the path the package isn't found, you'll still get an ImportError; but
it will be preceded by ImportWarnings showing you the non-package
directories found on the way.

The difference is that if you find a valid module package later on the
path, you'll still get warnings. 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. The symptom is usually a mysterious AttributeError
that takes a bit of determination to debug. Of course print
foo.__file__ usually sets you right, but that's not the first thing a
newbie would try -- they aren't quite sure about all the rules of
import, so they are likely to first try to fiddle with $PYTHONPATH or
sys.path, then put print statements in their package, etc.

> I'd probably make it that all directories that could have been imports
> get listed.

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

> FWIW I was definitely a kneejerk -1. After reading all the messages in
> this thread, I think I'm now a non-kneejerk -1. It seems like gratuitous
> change introducing inconsistency for minimal benefit - esp. if there is
> a notification that a directory *could* have been a package on import
> failure. I think it's a useful feature of Python that it's simple to
> distinguish a package from a non-package.

The change is only gratuitous if you disagree with it. The
inconsistency is real but we all know the line about a foolish
consistency. The benefit is minimal unless you've wasted an hour
debugging this situation.

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

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

--
--Guido van Rossum (home page: http://www.python.org/~guido/)