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

Delaney, Timothy (Tim) tdelaney at avaya.com
Thu Apr 27 01:48:55 CEST 2006

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

More information about the Python-Dev mailing list