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

[Glyph Lefkowitz]

On Tue, 12 Jun 2001, Tim Peters wrote:

[lots of stuff about floating point]

You know, it never ceases to amaze me how fascinating, subtle, and fun Tim
& co. make floating point math sound.  It always Just Works for me.  ;)

> In the background Guido is reworking Python's type and class model.  
> It should be possible after that's done to subclass from the builtin
> types.  If so, then you should be able to subclass the complex type
> and override its coercion policies.

Could somebody please explain to me why removing the type/class
distinction is a good idea?  I rather like the fact that it is readily
apparent which objects are implemented in Python and which in C (and my
code is rife with 'if type(xxx) is types.StringType'); if I can't
*implement* <type 'float'> in Python I don't understand why it makes sense
to subtype it.  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 a minor win (slightly less work
doing operator overloading to emulate dicts, lists, and floats) it seems
like an awful lot of work.  Is there something about writing extension
modules which will be different and better?


                      ______      __   __  _____  _     _
                     |  ____ |      \_/   |_____] |_____|
                     |_____| |_____  |    |       |     |
                     @ t w i s t e d m a t r i x  . c o m
                     http://twistedmatrix.com/users/glyph