Bug or Feature?

[Duncan Booth]

Stephan Diehl <stephan.diehl at gmx.net> wrote in
news:bpt5do$nls$04$1 at news.t-online.com: 

> Although, the question was more along the line, if (in the light of
> the principle of least surprise) this behaviour makes sense.
> My private opinion would be, that the usefullness of builtin types as
> real types would be much better, if they were safe under inheritance.
> 
There are some tradeoffs here.

I think that the majority of users would say that the speed of operations 
using 'int' is more important than the ease of inheriting from them. If you 
can make the 'int' operations work this way, but keep them at least as fast 
as they are today, then there may be a case for changing the behaviour.

The other problem though is that this would break backwards compatibility. 
For example if any code were to currently add booleans, it would suddenly 
get a boolean result. The (untested) code below, currently counts how many 
items in a list are greater than a specified value, but under your scheme 
it would return a boolean.

    def HowManyGreaterThan(aList, aValue):
        return reduce(operator.add, [ x > aValue for x in aList ])

I think what would be most useful would be new subclasses of int etc. which 
have the properties you desire, but you can write them yourself easily 
enough.

What rules, BTW, are you proposing for operations between two separate 
subclasses of int? e.g. given your mod7 class, and a corresponding mod9 
class should this print 3, 6, 24 or throw an exception?

    x = mod7(3)
    y = mod9(8)
    print x*y

and does this do the same?

    print y*x

-- 
Duncan Booth                                             duncan at rcp.co.uk
int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
"\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?