[Python-Dev] PEP 328

Thomas Wouters thomas at xs4all.net
Sat Feb 25 19:26:01 CET 2006

Since I implemented[*] PEP 328, Aahz suggested I take over editing the PEP,
too, as there were some minor discussion points to add still. I haven't been
around for the discussioons, though, and it's been a while for everone else,
I think, so I'd like to rehash and ask for any other open points.

The one open point that Aahz forwarded me, and is expressed somewhat in
http://mail.python.org/pipermail/python-dev/2004-September/048695.html , is
the case where you have a package that you want to transparently supply a
particular version of a module for forward/backward compatibility, replacing
a version elsewhere on sys.path (if any.) I see four distinct situations for

 1) Replacing a stdlib module (or a set of them) with a newer version, if the
    stdlib module is too old, where you want the whole stdlib to use the
    newer version.

 2) Same as 1), but private to your package; modules not in your package
    should get the stdlib version when they import the 'replaced' module.

 3) Providing a module (or a set of them) that the stdlib might be missing
    (but which will be a new enough version if it's there)

1) and 3) are easy to solve: put the module in a separate directory, insert
that into sys.path; at the front for 1), at the end for 3). Mailman, IIRC,
does this, and I think it works fine.

2) is easy if it's a single module; include it in your package and import it
relatively. If it's a package itself, it's again pretty easy; include the
package and include it relatively. The package itself is hopefully already
using relative imports to get sibling packages. If the package is using
absolute imports to get sibling packages, well, crap. I don't think we can
solve that issue whatever we do: that already breaks.

The real problem with 2) is when you have tightly coupled modules that are
not together in a package and not using relative imports, or perhaps when
you want to *partially* override a package. I would argue that tightly
coupled modules should always use relative imports, whether they are
together in a package or not (even though they should probably be in a
package anyway.) I'd also argue that having different modules import
different versions of existing modules is a bad idea. It's workable if the
modules are only used internally, but exposing anything is troublesome. for
instance, an instance of a class defined in foo (1.0) imported by bar will
not be an instance of the same class defined in foo (1.1) imported by

Am I missing anything?

([*] incorrectly, to be sure, but I have a 'correct' version ready that I'll
upload in a second; I was trying to confuse Guido into accepting my version,

Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

More information about the Python-Dev mailing list