Type/Class Distinction (was: RE: Future floating point directions? [was Re: floating point in 2.0])

[Tim Peters]

[Glyph Lefkowitz]
> Could somebody please explain to me why removing the type/class
> distinction is a good idea?

Have you read Guido's PEPs on the topic?

    http://python.sourceforge.net/peps/pep-0252.html
    http://python.sourceforge.net/peps/pep-0253.html
    http://python.sourceforge.net/peps/pep-0254.html

> I rather like the fact that it is readily apparent which objects
> are implemented in Python and which in C

Why would your code care what a thing is implemented in?  Right now it
sometimes *has* to care, but that's a consequence of the split.

> (and my code is rife with 'if type(xxx) is types.StringType');

That is a problem, but you already "should be" checking via

    isinstance(xxx, types.StringType)

instead.

> if I can't *implement* <type 'float'> in Python I don't understand
> why it makes sense to subtype it.

You're getting closer <wink>:  the reason you can't implement the float type
in Python is precisely because of the type/class split.

> It seems like an "OO purity" issue, and as we all know, practicality
> beats purity; but if Guido is personally working on it, there's
> surely something I'm missing.

For most apps most of the time it doesn't really make much difference.  The
problem is for extension writers, and even Python's own implementation,
because types and classes are implemented in entirely different ways,
leading to lots of irksome *almost*-duplication ("ok, if it's not an
instance, do this block of code, but if it is, do it this other strangely
twisted <wink> way").  Trying to implement a Python class in C is a close
approximation to hell now (this is why Jim Fulton created ExtensionClasses);
and trying to implement a Python type in Python is impossible now.

You should read the PEPs for details.  Note that the type/class split
doesn't really exist in Jython (they had no choice but to model everything
as "a class" there), so it's not like anyone should fear the C-based
language is going to fall apart at the seams.  It's a lot of work to heal in
CPython only because the split is so old and so deep.