Why does Python mix OO concepts and non OO concepts for operation s on basic types?

[Gerhard Häring]

* Michael P. Soulier <msoulier at mcss.mcmaster.ca_.nospam> [2002-05-22 22:59 +0000]:
> Actually, one of the few things I like about Ruby is that all objects
> in Ruby do have methods, and thus to add two numbers...
> 
>     2 + 4
>     2.+(4)
> 
>     are equivalent. 
> 
> Python _does_ seem mildly inconsistent in this regard.

That's a matter of taste. I'd like to know where this is a problem in
real life: you can use the special methods __add__, __sub__, __mul__,
and so on on any types/classes implementing the number protocol in
Python 2.2+. It's just that you have to play a trick with the Python
parser if you also want to make it work with number *literals*:

print (-2). __abs__(), 2. __add__(5)

But the only reason for using this with number literals is to make the
pure-OO crowd happy ;-)

> Giving strings methods helped a bit, but tuples still have none, and
> neither do numbers.

Wrong, both.

> >>> dir(())
> []
> >>> dir(2)
> []

Your Python is outdated. Try the same with Python 2.2+ where the start
of the type/class unification has taken place.

> IMHO, they should all be objects with methods and a class, such that they
> may be subclassed. 

They can. But in my experience it was easier to implement my own class
implementing the list or number protocol without subclassing the builtin
types.

Gerhard
-- 
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://www.cs.fhm.edu/~ifw00065/    OpenPGP public key id AD24C930
public key fingerprint: 3FCC 8700 3012 0A9E B0C9  3667 814B 9CAA AD24 C930
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))