typing "help(type)" gives the following documentation:
>>> help(type)
Help on class type in module __builtin__:
class type(object)
| type(object) -> the object's type
| type(name, bases, dict) -> a new type
"type" behaves both as a function, that reports the type of an object,
and as a factory type for creating types, as used mainly with
metaclasses.
calling the constructor of types, like lists, etc., is expected to
create a new instance of that type -- list() is a factory for lists,
dict() is a factory for dicts, etc.
but type() breaks this assumption. it behaves like a factory when
called with 3 params, but as a function when called with one param.
i find this overloading quite ugly and unnecessary.
more over, it can cause abominations like
>>> class x(type):
... pass
...
>>> x(1)
<type 'int'>
or
>>> list.__class__(1)
<type 'int'>
i suggest splitting this overloaded meaning into two separate builtins:
* type(name, bases, dict) - a factory for types
* typeof(obj) - returns the type of the object
this way, "type" retains it meaning as the base-class for all types,
and as a factory for types, while typeof() reports the object's type.
it's also more intuitive that typeof(1) returns, well, the *type of*
the
object 1.
no new keywords are needed, and code is always allowed to
override builtin functions, so i don't expect backward-
compatibility issues.
proposed schedule:
* 2.6 introduces typeof(), but type() with one argument retains its
old meaning
* 2.7 deprecates the usage of type() with a single argument
* 2.8 type is only a factory, while typeof replaces type() with a
single argument
comments are welcome.
-tomer
--
http://mail.python.org/mailman/listinfo/python-list
