[Python-Dev] Python 2.3a1 release -- Dec 31

[Just van Rossum]

Samuele Pedroni wrote:

> Indeed it seemed that there was consensus to want [__path__
> manipulations] (messy, hackish or whatever they may seem).

But, as I wrote, it *can't* work with importers in general. It can be
made to work with specific importers, such as zipimporter, but I don't
see the point (I'll rant about that in a second ;-).

> Honestly non considering the internals, the new __path__ conveys
> _less_ information that it could. That's the crucial point in my
> eyes.

For zipimporter, yes, you can see it that way. I just think it conveys
*different* information.

> I'm -1 on the changes.

:-(

I still have to see an example of a pkg.__path__ manipulation in which
the intentions couldn't be solved in a different way, for example like
how os.py imports platform-specific features. If os.py would have done
that by munging sys.path everybody would have been appalled.

The more I think about it, the more I think we should deprecate __path__
altogether. The path import mechanism code could just as well look for
"package/submodule.py" on sys.path (which would in fact make pkgutils.py
redundant as the feature it currently implements would then be standard
behavior). That's a bit extreme and is perhaps not even doable in a 100%
b/w compatible way, yet I do believe __path__ was a design mistake.
http://www.python.org/doc/essays/packages.html doesn't explain the
rationale as to why this particular solution was chosen; I _suspect_ it
was simply an easy solution that left much of the lower level import
logic unchanged. If that's true, then being able to modify pkg.__path__
is merely a side effect of the chosen solution. I could be wrong,
though...

Repackaging applications for use by end users (with freeze, py2exe, etc)
should be easy and straightforward. Manipulating pkg.__path__ makes this
harder than neccesary and that alone should be reason enough to strongly
discourage it.

Just