[Python-3000] Types and classes

[Guido van Rossum]

No, we're not renaming fundamentals like that. 3.0a4 goes out tomorrow
and we want stability.

On Wed, Apr 2, 2008 at 4:39 PM, Robert Brewer <fumanchu at aminus.org> wrote:
> Guido van Rossum wrote:
>  > On Wed, Apr 2, 2008 at 11:57 PM,
>  > Paul Prescod <paul at prescod.net> wrote:
>  > > But does anyone else find it odd that the types of some things
>  > > are classes and the classes of some things are types?
>  > >
>  > > >>> type(socket.socket())
>  > > <class 'socket.socket'>
>  > > >>> type("abc")
>  > > <type 'str'>
>  > > >>> socket.socket().__class__
>  > > <class 'socket.socket'>
>  > > >>> "abc".__class__
>  > > <type 'str'>
>  > >
>  > > In a recent talk I could only explain this as a historical quirk.
>  > > As I understand, it is now possible to make types that behave
>  > > basically exactly like classes and classes that behave exactly
>  > > like types. Is there any important difference between them anymore?
>  >
>
> > I think it's still just a historical quirk; maybe we should bite the
>  > bullet and fix this in py3k. (Still, 'type' and 'class' will both be
>  > part of the language, one as a built-in function and metaclass, the
>  > other as a keyword.)
>
>  That's...grating, but livable. Maybe we should change "class" to
>  "classdef" and "type" to "class" so code like "isinstance(x, type)"
>  doesn't look so...wrong.
>
>  On the other hand, why is there no "function" builtin/metaclass to go
>  with the "def" keyword? The asymmetry implies a semantic conflict
>  somewhere (it doesn't *prove* that, just implies).
>
>
>  Robert Brewer
>  fumanchu at aminus.org
>
>



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