[Python-Dev] PendingDeprecationWarning

[Oren Tirosh]

On Wed, May 29, 2002 at 12:40:02PM -0400, Raymond Hettinger wrote:
> From: "Guido van Rossum" <guido@python.org>
> > Thanks!  I agree with the name change to PendingDeprecationWarning.
> > Check it in before I change my mind! :-)
> 
> Awesome!
> Now, down to business.
> What shall we Silently Deprecate?
> 
> string module
> types module (after providing substitutes)

It looks like many of the names in the types module already have substitutes 
in __builtins__:  

>>> import types
>>> for name, t in types.__dict__.items():
...   if type(t) is type and hasattr(__builtins__, t.__name__):
...     print 'types.%s -> %s' % (name, t.__name__)
...
types.IntType -> int
types.TypeType -> type
types.StringType -> str
types.FloatType -> float
types.ObjectType -> object
types.DictionaryType -> dict
types.FileType -> file
types.DictType -> dict
types.ListType -> list
types.TupleType -> tuple
types.LongType -> long
types.BufferType -> buffer
types.UnicodeType -> unicode
types.ComplexType -> complex
types.SliceType -> slice
types.XRangeType -> xrange

Some of these are new in 2.2 (like object, dict and file).  Some of them 
used to be functions before Python 2.2 (like str, int and list).  Three of
them are still builtin functions in Python 2.2: xrange, buffer and slice. 
Perhaps they should also be converted to types for consistency.

Some more factory functions that could be unified with the type of the 
objects they create module can be found in the new module.  They, too can 
be used as substitutes for names in the types module.

>>> import new
>>> for name, t in types.__dict__.items():
...   if type(t) is type and hasattr(new, t.__name__):
...     print 'types.%s -> new.%s -> %s' % (name, t.__name__, t.__name__)
types.CodeType -> new.code -> code
types.ModuleType -> new.module -> module
types.LambdaType -> new.function -> function
types.InstanceType -> new.instance -> instance
types.FunctionType -> new.function -> function

There are two that almost made it to this list but the name of the factory 
function in module new is not exactly the same as the type's __name__:

types.MethodType -> new.instancemethod -> instancemethod ('instance method')
types.ClassType -> new.classobj -> classobj ('class')

For instancemethod it's easy to remove the space from the type's __name__.
The word class is a reserved word.  The type's __name__ could be changed 
to 'classobj' to match the factory function's name. Some other alternatives 
I can think of are 'class_', 'ClassType' or 'classtype'.

Instances of the remaining types can't be instanciated from Python code.  
Most of them can be safely identified by their __name__:

types.BuiltinMethodType -> builtin_function_or_method
types.BuiltinFunctionType -> builtin_function_or_method
types.TracebackType -> traceback
types.GeneratorType -> generator
types.FrameType -> frame
types.NoneType -> NoneType

The last two remaining troublemakers:

types.DictProxyType -> dict_proxy ('dict-proxy')
   'dict-proxy' is not a valid Python identifier. 

types.EllipsisType -> EllipsisType ('ellipsis')
   The name 'ellipsis' is easily confused with 'Ellipsis'. The name 
   EllipsisType is consistent with NoneType. Both are the type of a 
   specific singleton object.

Should all these names be added to __builtins__?  Many of them are not very
useful in everyday programming.  Perhaps the less important ones can be put
away in some module. 

Now how should that module be named? Ummm... maybe 'types'? :-)

       Oren