On Wed, May 29, 2002 at 12:40:02PM -0400, Raymond Hettinger wrote:
From: "Guido van Rossum"
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