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).