[Python-3000] Fwd: proposal: disambiguating type

Guido van Rossum guido at python.org
Mon May 22 22:35:01 CEST 2006


I think this is a reasonable suggestion. Perhaps less code would break
if you renamed the metaclass instead of the inquiry function.

--Guido

On 5/22/06, tomer filiba <tomerfiliba at gmail.com> wrote:
> 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

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-3000 mailing list