[XML-SIG] Python package name

[Guido van Rossum]

> Perhaps a good start would be using lib/python-2.0.0 as installation
> target rather than just lib/python2. I'm sure this was discussed
> before, but given the problems we had with this during the 1.5
> cycle (with 1.5.2 providing not only patches, but also new
> features), I think a more fine-grained approach should be
> considered for future versions.

We're using lib/python2.0, and we plan not to make major releases with
a 3rd level version number increment!  SO I think that's not necessary.

> About package versioning: how would the version be specified
> in imports ?
> 
> from mx.DateTime(1.4.0) import now
> from mx(1.0.0).DateTime import now
> from mx(1.0.0).DateTime(1.4.0) import now
> 
> The directory layout would then look something like this:
> 
> mx/
> 	1.0.0/
> 		DateTime/
> 			1.4.0/
> 
> Package __path__ hooks could be used to implement the
> lookup... or of course some new importer.
> 
> But what happens if there is no (old) version mx-1.0.0 installed ?
> Should Python then default to mx-1.3.0 which is installed or
> raise an ImportError ?
> 
> This sounds like trouble... ;-)

You've got it.  Please move this to python-dev.  It's good PEP
material!

> > > We will have a similar problem with Unicode and the stdlib
> > > during the Python 2.0 cycle: people will want to use Unicode
> > > together with the stdlib, yet many modules in the stdlib
> > > don't support Unicode. To remedy this, users will have to
> > > patch the stdlib modules and put them somewhere so that they
> > > can override the original 2.0 ones.
> > 
> > They can use $PYTHONPATH.
> 
> True, but why not help them a little by letting site
> installations override the stdlib ? After all, distutils
> standard target is site-packages.

Overrides of the stdlib are dangerous in general and should not be
encouraged.

> > > BTW, with distutils coming on strong I don't really see a
> > > need for any hacks: instead distutils should be given some
> > > smart logic to do the right thing, ie. it should support
> > > installing subpackages of a package. If that's not desired,
> > > then I'd opt for overriding the whole package (without any
> > > hacks to import the overridden one).
> > 
> > That's another possibility.  But then distutils will have to become
> > aware of package versions again.
>  
> This shouldn't be hard to add to the distutils processing:
> before starting an installation of a package, the package
> pre-install hook could check which versions are installed
> and then decide whether to raise an exception or continue.

Here's another half-baked idea about versions: perhaps packages could
have a __version__.py file?

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)