[Python-Dev] python package

[M.-A. Lemburg]

Guido van Rossum wrote:
>>Guido van Rossum wrote:
>>
>>>I have thought some more about the idea of moving the entire stdlib
>>>into a package named "python" and I reject the idea.
>>>
>>>Think of the impact the change would have on the tutorial.
>>>
>>>Think of the amount of needless changes to perfectly working code it
>>>would entail.
>>>
>>>If you want to avoid 3rd party module/package names to be invalidated
>>>by additions to the standard library, you might just as well introduce
>>>a "nonstd" package into which all 3rd party extensions must be placed.
>>>This at least doesn't require people who don't use 3rd party code to
>>>change their programs.
>>
> 
> [MAL]
> 
>>Uhm, the point I was trying to make was to provide a long
>>running upgrade path from the current situation (everthing is
>>top-level) to the single package structure.
> 
> 
> And my suggestion of a "nonstd" toplevel package had the same goal. :-)

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.

>>It is fairly easy to move from 'import os' to 'from python import os',
>>but I understand that people will not want to do this until
>>Python 3.
>>
>>I was not suggesting to start breaking code by enforcing this
>>strategy in some way, I just though it would be a good idea
>>to start providing means to work with the single python package
>>approach now to make the transition less painful in Python 3.
> 
> 
> Two problems.  First, your proposal has lots of practical warts that I
> already pointed out; your suggestion to fix one of them by making all
> the old names stubs would require a massive set of changes to the CVS
> repository.  Second, I don't think a 'python' toplevel package is the
> right solution.
> 
> 
>>>Maybe we should create a standard package hierarchy; Eric Raymond once
>>>started working on such a proposal but I have discouraged him because
>>>I think it would cause too much upheaval.  But for Python 3 I would
>>>consider it.
>>
>>That's what I was targetting :-)
> 
> 
> 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.

-- 
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/