PEP 294: Type Names in the types Module

PEP: 294 Title: Type Names in the types Module Version: $Revision: 1.1 $ Last-Modified: $Date: 2002/06/23 23:52:19 $ Author: oren at hishome.net (Oren Tirosh) Status: Draft Type: Standards track Created: 19-Jun-2002 Python-Version: 2.3 Post-History: Abstract This PEP proposes that symbols matching the type name should be added to the types module for all basic Python types in the types module: types.IntegerType -> types.int types.FunctionType -> types.function types.TracebackType -> types.traceback ... The long capitalized names currently in the types module will be deprecated. With this change the types module can serve as a replacement for the new module. The new module shall be deprecated and listed in PEP 4. Rationale Using two sets of names for the same objects is redundant and confusing. In Python versions prior to 2.2 the symbols matching many type names were taken by the factory functions for those types. Now all basic types have been unified with their factory functions and therefore the type names are available to be consistently used to refer to the type object. Most types are accessible as either builtins or in the new module but some types such as traceback and generator are only accssible through the types module under names which do not match the type name. This PEP provides a uniform way to access all basic types under a single set of names. Specification The types module shall pass the following test: import types for t in vars(types).values(): if type(t) is type: assert getattr(types, t.__name__) is t The types 'class', 'instance method' and 'dict-proxy' have already been renamed to the valid Python identifiers 'classobj', 'instancemethod' and 'dictproxy', making this possible. Backward compatibility Because of their widespread use it is not planned to actually remove the long names from the types module in some future version. However, the long names should be changed in documentation and library sources to discourage their use in new code. Reference Implementation A reference implementation is available in SourceForge patch #569328: http://www.python.org/sf/569328 Copyright This document has been placed in the public domain.

I'd like to reject PEP 294. Adding the type names that are already builtins to types.py is definitely a bad idea (the patch is full of lines like "int = int" -- this can only serve to confuse). I propose to leave types.py alone. If we need a place to name types that don't deserve being builtins, perhaps new.py is a better place? --Guido van Rossum (home page: http://www.python.org/~guido/)

On Fri, Jul 12, 2002 at 11:01:22AM -0400, Guido van Rossum wrote:
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? The idea of using the types module turned out to have more problems than appeared at first but new doesn't look much better to me. Anyone has other suggestions? Oren

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.
The idea of using the types module turned out to have more problems than appeared at first but new doesn't look much better to me.
Using new.py looks much better to me because it already works. --Guido van Rossum (home page: http://www.python.org/~guido/)

"GvR" == Guido van Rossum <guido@python.org> writes:
GvR> Sometimes you ask too many questions. :-) GvR> Let's just say that this is a historically available name. I GvR> don't expect that isinstance(obj, generator) is a very common GvR> question to ask, so I don't mind if you have to ask it in a GvR> somewhat awkward way. I recently wrote some code that needed to look for functions. I wrote it this way: from new import function # ... if isinstance(obj, function): # ... It didn't look odd at all. And I don't care much where I import function from. I wouldn't mind if all the type objects defined in new where available in types. IOW, the names exported by new could also be exported by types. This means types would fall into two categories: types with builtin names and types available in the types module. I expect the current set of types with builtin names is sufficient. Jeremy

No, the docs for types.py promises that it only exports names ending in 'Type'. That's not a promise I want to break lightly.
This is already the case, but the names exported by types.py don't match the __name__ attribute of those types. Is that a problem? --Guido van Rossum (home page: http://www.python.org/~guido/)

On Fri, Jul 12, 2002 at 12:06:25PM -0400, Jeremy Hylton wrote:
That's exactly what PEP 294 proposed. The primary objection was that the documentation for the types module says that names exported by future versions will all end in "Type". People that do 'from types import *' based on this promise will tend to get offended if a variable called 'code' is clobbered. Anyway, my mother also told me that breaking promises is not a nice thing to do so I try to keep that in mind when I design programming interfaces. Oren

Oren Tirosh <oren-py-d@hishome.net>:
The primary objection was that the documentation for the types module says that names exported by future versions will all end in "Type".
Suggestion: Introduce a new module called "newtypes". You can interpret this name two ways: the module containing all the new names for the types, and the module you use when you want to create a new instance of a type! Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+

I'd like to reject PEP 294. Adding the type names that are already builtins to types.py is definitely a bad idea (the patch is full of lines like "int = int" -- this can only serve to confuse). I propose to leave types.py alone. If we need a place to name types that don't deserve being builtins, perhaps new.py is a better place? --Guido van Rossum (home page: http://www.python.org/~guido/)

On Fri, Jul 12, 2002 at 11:01:22AM -0400, Guido van Rossum wrote:
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? The idea of using the types module turned out to have more problems than appeared at first but new doesn't look much better to me. Anyone has other suggestions? Oren

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.
The idea of using the types module turned out to have more problems than appeared at first but new doesn't look much better to me.
Using new.py looks much better to me because it already works. --Guido van Rossum (home page: http://www.python.org/~guido/)

"GvR" == Guido van Rossum <guido@python.org> writes:
GvR> Sometimes you ask too many questions. :-) GvR> Let's just say that this is a historically available name. I GvR> don't expect that isinstance(obj, generator) is a very common GvR> question to ask, so I don't mind if you have to ask it in a GvR> somewhat awkward way. I recently wrote some code that needed to look for functions. I wrote it this way: from new import function # ... if isinstance(obj, function): # ... It didn't look odd at all. And I don't care much where I import function from. I wouldn't mind if all the type objects defined in new where available in types. IOW, the names exported by new could also be exported by types. This means types would fall into two categories: types with builtin names and types available in the types module. I expect the current set of types with builtin names is sufficient. Jeremy

No, the docs for types.py promises that it only exports names ending in 'Type'. That's not a promise I want to break lightly.
This is already the case, but the names exported by types.py don't match the __name__ attribute of those types. Is that a problem? --Guido van Rossum (home page: http://www.python.org/~guido/)

On Fri, Jul 12, 2002 at 12:06:25PM -0400, Jeremy Hylton wrote:
That's exactly what PEP 294 proposed. The primary objection was that the documentation for the types module says that names exported by future versions will all end in "Type". People that do 'from types import *' based on this promise will tend to get offended if a variable called 'code' is clobbered. Anyway, my mother also told me that breaking promises is not a nice thing to do so I try to keep that in mind when I design programming interfaces. Oren

Oren Tirosh <oren-py-d@hishome.net>:
The primary objection was that the documentation for the types module says that names exported by future versions will all end in "Type".
Suggestion: Introduce a new module called "newtypes". You can interpret this name two ways: the module containing all the new names for the types, and the module you use when you want to create a new instance of a type! Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
participants (5)
-
Greg Ewing
-
Guido van Rossum
-
Jeremy Hylton
-
Oren Tirosh
-
Oren Tirosh