proposal: disambiguating type

[gangesmaster]

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