[Python-Dev] python package

[Michael McLay]

On Friday 12 July 2002 02:42 pm, Guido van Rossum wrote:
> [me] ...
> Uh?  Who is proposing to name it "new"?  Not me!  Maybe you should
> read the entire thread again? :-)

Ok, I guess I'm just a bit more confused than usual today. I had also read the 
following message and made the unfortunate assumption that you were proposing 
"new" as the name of a new top level module to contain all the standard 
python modules. Opps I merged the threads in my head.

On Friday 12 July 2002 11:51 am, Guido van Rossum wrote:
> > > If we need a place to name types that don't deserve being builtins,
> > > perhaps new.py is a better place?
> >
> > The new. prefix is natural enough for
> >
> > 	m = new.module('name')
> >
> > type but it looks pretty awkward in
> >
> > 	if isinstance(obj, new.generator):
> >
> > What's the meaning of 'new' in this context?
>
> Sometimes you ask too many questions. :-)
>
> Let's just say that this is a historically available name.  I don't
> expect that isinstance(obj, generator) is a very common question to
> ask, so I don't mind if you have to ask it in a somewhat awkward way.

Now back to the issue of moving all the top level names in the standard 
distribution into a "python" namespace. For the remainder of the 2.X release 
cycle it is important to not remove the existing names from the top level 
namespace. However, it might be reasonable to move all standard distribution 
names into a single top level namespace and grandfather the existing top 
level names into the top level namespace for the remainder of the 2.x series. 
The existing set of names would be available from either namespace. All new 
names for the standard distribution would only be placed in the new top level 
standard package namespace. 

With this approach all old names would still be accessible to the existing 
code base as top level names and introducing new names to the standard 
distribution will not clobber third party modules and packages. For the 
remainder of 2.X the rules will be messy because some standard names will be 
accessible from either the top level namespace or from the standard "python" 
namespace. Then for Python 3.0 the grandfathered names would be removed from 
the top level namespace. This approach should enable a smoother transition in 
the documentation and coding practices.

The preferred coding style guide, the tutorial, and other documentation would 
be used to explain the transition plan. The new guidelines would promote the 
use of the new namespace for all cases, but it would not preclude the use of 
the older coding style. 

I"m not keen on the use the name "python" for the top level namespace. Perhaps 
the name "std" would be more desirable (and shorter to type).