[Python-3000] Fwd: proposal: disambiguating type
tomer filiba
tomerfiliba at gmail.com
Mon May 22 21:29:39 CEST 2006
forwarded from c.l.p -- they said it is better suited for python3k as it
break things
-----
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 mymetaclass(type):
... pass
...
>>> mymetaclass(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 its 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 there's no need for "from __future__
import blah" kind of stuff.
---
notes on compatibility: it would be easy to write an external tool
that mechanically replaces "type(obj)" with "typeof(obj)"... which
also proves the point type(obj) and type(n, b, d) are fundamentally
different and shouldn't share the same overloaded name.
comments?
-tomer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060522/646400ec/attachment.htm
More information about the Python-3000
mailing list