[Python-Dev] python package

[M.-A. Lemburg]

Guido van Rossum wrote:
>>With the exception that we have control over the Python core
>>code while we don't over third party extensions, so providing
>>means to simplify the transition for the standard lib is easier
>>than trying to enforce your proposed 'nonstd' package.
> 
> 
> I think you could get a long way with minor changes along the lines of
> making site-packages a package itself.

This wouldn't work since in that case you'd have the problem
of having to fix class names in e.g. pickles for objects
which you don't know anything about. We do know about objects
in the Python standard lib, so we could take care to have mechanisms
like pickle deal with them properly.

>>>Then please think about a proper solution rather than proposing
>>>something whose only virtue seems to be that you can implement a poor
>>>approximation of it in two lines.
>>
>>Just testing waters here... there's no point in trying to
>>find a solution to something which is not regarded as problem
>>anyway.
> 
> 
> You started by claiming that there's a problem: expansion of the
> stdlib could conflict with 3rd party module/package names.
> 
> I don't regard it as a problem that's so bad that we need to make big
> changes to solve it.

I believe that the more Python grows (not only the core,
but the complete set of available modules and packages in
the Python universe), the less likely we are going to
hit a problem.

> If you still think a solution is desired, you could start by proposing
> a new standard package hierarchy.  Then new standard modules could be
> placed in that new hierarchy rather than at the top level.
> 
> I'm rejecting the proposal of a single top-level package named "python".

You've written that before, but you still haven't given any
explanation of why a single package would be worse than a
multi-level hierarchy of modules (e.g. grouped by application
space).

I think that simply moving to one package would cause less
breakage and make the whole transition process much easier
than having to tweak code into using some complicated
multi-package structure.

FWIW, I've been through all this with the mx packages
and using a single new package caused the least amount
of work. Even better: it turned out to be easy to provide
backwards compatibility code so that applications still
using the old layout continue to run, but start using the
new structure in their pickles.

No need to get heated, though. I just thought that it would
be a good time to start thinking about this option again.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
_______________________________________________________________________
eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,...
Python Consulting:                               http://www.egenix.com/
Python Software:                    http://www.egenix.com/files/python/