[Import-SIG] Suggested example/use case for PEP 402's extensible packages

[Nick Coghlan]

When Tarek asked for help with the packaging->distutils2 backport, the
question came up as to *why* the backport was being distributed under
a different name. The rationale put forward was that it allowed the
future 3.4 version to be backported to 3.3 without conflicting with
the standard library version. A similar convention is already in place
for backports like unittest -> unittest2 and it seems to work well in
practice, despite being somewhat ugly.

In a world with extensible (virtual) packages, as proposed by PEP 402,
it would be straightforward to instead adopt a namespace convention
for such standard lib backports, such as "backports.packaging" and
"backports.unittest" rather than having to mangle the name of the
package itself. With the standard import mechanism properly on
sys.meta_path (as it should be in 3.3), it would even be possible to
define a meta importer that checked for such backports automatically
if the ordinary import process failed.

Obviously, this is a far future kind of thing, only feasible when 3.3
is the oldest version a backport wants to support, rather than the
newest, but I like it as an example of what extensible package
namespaces allows.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia