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

[Heiko Wundram]

Am Sonntag 21 Mai 2006 21:13 schrieb gangesmaster:

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

While I personally don't find this proposal to be bad, this is something that
should only be considered for Python 3000, because it breaks old code in very
unnecessary ways (because it's only for "beauty", not for function),
considering that most scripts written for Python 1.5.2 still work under
current Python without modification, and people expect them to.

--- Heiko.