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

[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.  ;)

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

                      ______      __   __  _____  _     _
                     |  ____ |      \_/   |_____] |_____|
                     |_____| |_____  |    |       |     |

                      http://www.*-*-*.com/



Sat, 29 Nov 2003 17:30:21 GMT  
 Type/Class Distinction (was: RE: Future floating point directions? [was Re: floating point in 2.0])

Quote:

> 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

There is no problem in it being apparent, but being able to certain
things only to one kind of objects is rather limiting. I could list
many applications in which it would be convenient to subclass a
built-in type, for example.
--
-------------------------------------------------------------------------------

Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------


Sat, 29 Nov 2003 21:55:24 GMT  
 Type/Class Distinction (was: RE: Future floating point directions? [was Re: floating point in 2.0])

Quote:


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



Wed, 03 Dec 2003 03:57:45 GMT  
 Type/Class Distinction (was: RE: Future floating point directions? [was Re: floating point in 2.0])

    ...

Quote:
> 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):

You're behind the times, I think (if I understand you correctly):

D:\py21>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
Alternative ReadLine 1.4 -- Copyright 2001, Chris Gonnerman

Quote:
>>> int=type(1)
>>> isinstance(23,int)
1
>>> isinstance(23L,int)
0

i.e., isinstance already accepts a type-object 2nd argument.

What you can't yet do is INHERIT from a type, &c...

Alex



Wed, 03 Dec 2003 22:05:04 GMT  
 Type/Class Distinction (was: RE: Future floating point directions? [was Re: floating point in 2.0])

[discussion about type/class split]

Quote:

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

You already can, more-or-less:

Python 2.1 (#92, Apr 24 2001, 23:59:43)  [CW CARBON GUSI2 THREADS]

Quote:
>>> from types import *
>>> isinstance(5, IntType)
1
>>> isinstance(1.0, IntType)

0

Quote:
> No more special casing seems good to me.

Where the PEP will help is to avoid having to do things like:

if isinstance(spam, ListType) or isinstance(spam, UserList):
    ...

and also, presumably, to help C extensions use UserLists and similar
objects interchangeably with lists.

Regards,
Corran



Wed, 03 Dec 2003 23:59:28 GMT  
 Type/Class Distinction (was: RE: Future floating point directions? [was Re: floating point in 2.0])

Quote:



>    ...
>> 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):
> You're behind the times, I think (if I understand you correctly):

So I am! I wasn't aware this was the case. Does not seem to be mentioned in
Andrew Kuchling's 'What's new in Python 2.1'. Apparently we're on our
way already then.

Regards,

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



Thu, 04 Dec 2003 03:31:35 GMT  
 Type/Class Distinction (was: RE: Future floating point directions? [was Re: floating point in 2.0])

Quote:




> >    ...
> >> 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):

> > You're behind the times, I think (if I understand you correctly):

> So I am! I wasn't aware this was the case. Does not seem to be mentioned in
> Andrew Kuchling's 'What's new in Python 2.1'.

Well, that would be because it wasn't "new in Python 2.1";

    >>> import types
    >>> isinstance(1, types.IntType)
    1

works in 1.5.2 (the oldest version I have lying around).

I found:

-----------------
revision 2.112
date: 1997/12/02 19:11:45;  author: guido;  state: Exp;  lines: +15 -10
Support type objects in isinstance().

E.g. isinstance('',types.StringType) will return true now instead of
raising a TypeError exception.  This is for JPython compatibility.
-----------------

in the CVS logs for Python/bltinmodule.c, which seems to be just
before Python 1.5 came out.

Cheers,
M.

--
 The rapid establishment of social ties, even of a fleeting nature,
 advance not only that goal but its standing in the uberconscious
 mesh of communal psychic, subjective, and algorithmic interbeing.
 But I fear I'm restating the obvious.  -- Will Ware, comp.lang.python



Thu, 04 Dec 2003 17:12:29 GMT  
 Type/Class Distinction (was: RE: Future floating point directions? [was Re: floating point in 2.0])
[Glyph Lefkowitz]

Quote:
> 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

Quote:
> 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.

Quote:
> (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.

Quote:
> 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.

Quote:
> 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.



Fri, 05 Dec 2003 08:37:14 GMT  
 Type/Class Distinction (was: RE: Future floating point directions? [was Re: floating point in 2.0])

[snip]

Quote:
>> > You're behind the times, I think (if I understand you correctly):

>> So I am! I wasn't aware this was the case. Does not seem to be mentioned in
>> Andrew Kuchling's 'What's new in Python 2.1'.
> Well, that would be because it wasn't "new in Python 2.1";
>    >>> import types
>    >>> isinstance(1, types.IntType)
>    1
> works in 1.5.2 (the oldest version I have lying around).

Duh. (hits himself in the head) :)

Shows you how often I use 'isinstance()'!

I'll-go-back-to-*deliberately*-silly-posts-now-ly yours,

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



Sat, 06 Dec 2003 02:02:40 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. Canvas: Am I headed in the right direction?

2. I am not deaf, but am I mute?

3. Fixed point math in asm -HELP ME I 'am dying here

4. An alternative to floating point (was Re: Floating point non-exactness)

5. IBM 370 Floating point to IEEE floating point

6. Am lost in ObjetLand... (BaseHTTPServer class hierarchy)

7. Floating Point type in VHDL ?

8. Precision of Floating Point Types

9. Floating-Point Types

10. identify floating-point types

11. Floating point types

12. Floating point types and infinity closure info needed

 

 
Powered by phpBB® Forum Software