Why are there no 'set' and 'frozenset' types in the 'types' module?
Sorry if I am asking the obvious, but why are the aliases of set types not included in the 'types' module? I thought for a moment that they are just classes, but no, they introduce themselves as built-in types, just like any other standard Python type.
print type(set([1, 2, 4])) <type 'set'>
print type(frozenset([3, 5])) <type 'frozenset'>
Is it intentional, or is there some meaning behind this? If not, shouldn't they be added to the module? Regards, Bartosz Tarnowski --------------------------------------------------------------- Darmowy program do wypełniania PIT: http://linkint.pl/f2931
On Mon, 25 Apr 2011 14:04:35 +0200 haael <haael@interia.pl> wrote:
Sorry if I am asking the obvious, but why are the aliases of set types not included in the 'types' module?
Because there's no reason to include them, since they are already in the root (builtins) namespace. You'll notice that in Python 3, the "types" module only contains types which are not obviously accessed through easier means:
dir(types) ['BuiltinFunctionType', 'BuiltinMethodType', 'CodeType', 'FrameType', 'FunctionType', 'GeneratorType', 'GetSetDescriptorType', 'LambdaType', 'MemberDescriptorType', 'MethodType', 'ModuleType', 'TracebackType', '__builtins__', '__cached__', '__doc__', '__file__', '__name__', '__package__']
Regards Antoine.
Because there's no reason to include them, since they are already in the root (builtins) namespace.
You'll notice that in Python 3, the "types" module only contains types which are not obviously accessed through easier means:
OK, makes sense, but in this case it would be handy to have some list of all possible built-in types. I was just creating one and I nearly missed sets. If an entry in 'types' module is too much, there should be some comprehensive list in the documentation at least. Regards, Bartosz Tarnowski --------------------------------------------- Ksiegowa radzi: Jak zaÅozyc firme w 15 minut? http://linkint.pl/f2968
2011/4/25 haael <haael@interia.pl>:
Because there's no reason to include them, since they are already in the root (builtins) namespace.
You'll notice that in Python 3, the "types" module only contains types which are not obviously accessed through easier means:
OK, makes sense, but in this case it would be handy to have some list of all possible built-in types. I was just creating one and I nearly missed sets. If an entry in 'types' module is too much, there should be some comprehensive list in the documentation at least.
http://docs.python.org/dev/library/stdtypes -- Regards, Benjamin
On 02:01 pm, haael@interia.pl wrote:
Because there's no reason to include them, since they are already in the root (builtins) namespace.
You'll notice that in Python 3, the "types" module only contains types which are not obviously accessed through easier means:
OK, makes sense, but in this case it would be handy to have some list of all possible built-in types. I was just creating one and I nearly missed sets. If an entry in 'types' module is too much, there should be some comprehensive list in the documentation at least.
Maybe this is what you're after?
pprint([t for t in object.__subclasses__() if t.__module__ == '__builtin__']) [<type 'type'>, <type 'weakref'>, <type 'weakcallableproxy'>, <type 'weakproxy'>, <type 'int'>, <type 'basestring'>, <type 'bytearray'>, <type 'list'>, <type 'NoneType'>, <type 'NotImplementedType'>, <type 'traceback'>, <type 'super'>, <type 'xrange'>, <type 'dict'>, <type 'set'>, <type 'slice'>, <type 'staticmethod'>, <type 'complex'>, <type 'float'>, <type 'buffer'>, <type 'long'>, <type 'frozenset'>, <type 'property'>, <type 'tuple'>, <type 'enumerate'>, <type 'reversed'>, <type 'code'>, <type 'frame'>, <type 'builtin_function_or_method'>, <type 'instancemethod'>, <type 'function'>, <type 'classobj'>, <type 'dictproxy'>, <type 'generator'>, <type 'getset_descriptor'>, <type 'wrapper_descriptor'>, <type 'instance'>, <type 'ellipsis'>, <type 'member_descriptor'>, <type 'EncodingMap'>, <type 'module'>, <type 'classmethod'>, <type 'file'>]
Jean-Paul
Because there's no reason to include them, since they are already in the root (builtins) namespace.
You'll notice that in Python 3, the "types" module only contains types which are not obviously accessed through easier means:
OK, makes sense, but in this case it would be handy to have some list of all possible built-in types. I was just creating one and I nearly missed sets. If an entry in 'types' module is too much, there should be some comprehensive list in the documentation at least.
Maybe this is what you're after?
pprint([t for t in object.__subclasses__() if t.__module__ == '__builtin__']) [<type 'type'>, <type 'weakref'>, <type 'weakcallableproxy'>, <type 'weakproxy'>, <type 'int'>, <type 'basestring'>, <type 'bytearray'>, <type 'list'>, <type 'NoneType'>, <type 'NotImplementedType'>, <type 'traceback'>, <type 'super'>, <type 'xrange'>, <type 'dict'>, <type 'set'>, <type 'slice'>, <type 'staticmethod'>, <type 'complex'>, <type 'float'>, <type 'buffer'>, <type 'long'>, <type 'frozenset'>, <type 'property'>, <type 'tuple'>, <type 'enumerate'>, <type 'reversed'>, <type 'code'>, <type 'frame'>, <type 'builtin_function_or_method'>, <type 'instancemethod'>, <type 'function'>, <type 'classobj'>, <type 'dictproxy'>, <type 'generator'>, <type 'getset_descriptor'>, <type 'wrapper_descriptor'>, <type 'instance'>, <type 'ellipsis'>, <type 'member_descriptor'>, <type 'EncodingMap'>, <type 'module'>, <type 'classmethod'>, <type 'file'>]
Jean-Paul
Yes, something like that, but without abstract types like 'basestring'. If abstract types were OK, it would suffice to use 'object'. The use case is designing protocols that export Python objects to outer world, 'pickle' is an example. One needs to typecase through all built-in Python types and handle them in some way. Nevertheless, my problem is solved. Thank you. Regards, Bartosz Tarnowski --------------------------------------------------------------- Darmowy program do wypeÅniania PIT: http://linkint.pl/f2931
On Mon, Apr 25, 2011 at 8:04 AM, haael <haael@interia.pl> wrote:
Sorry if I am asking the obvious, but why are the aliases of set types not included in the 'types' module? I thought for a moment that they are just classes, but no, they introduce themselves as built-in types, just like any other standard Python type.
The types module pre-dates the time when classes were actually types in their own right, and many of the built-in constructors, like "float", "int", and "list", were simply functions. When that was the case: >>> import types >>> types.IntType == int False For types that have always been types, there's no corresponding entry in the types module, nor is there any need for any, since the type itself is already accessible. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> "Give me the luxuries of life and I will willingly do without the necessities." --Frank Lloyd Wright
participants (5)
-
Antoine Pitrou -
Benjamin Peterson -
exarkun＠twistedmatrix.com -
Fred Drake -
haael