[Python-Dev] Dropping init.py requirement for subpackages (original) (raw)

Guido van Rossum guido at python.org
Thu Apr 27 01:32:20 CEST 2006

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/)

More information about the Python-Dev mailing list