Type/Class Distinction

[Martijn Faassen]

Glyph Lefkowitz <glyph at twistedmatrix.com> wrote:

> 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?

Right now we have to *treat* 'types' differently from 'classes'. For
built-in objects you have to use the type() construct to check what
you're dealing with, but for class instances you use isinstance().

Wouldn't it be nice if the language allowed something like this:

if isinstance(foo, int):
    ...
elif isinstance(foo, BarClass):
    ...

(backwards compatibility issues aside)

No more special casing seems good to me.

Regards,

Martijn
-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?