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

[Chris Liechti]

Syver Enstad <syver-en+usenet at online.no> wrote in 
news:u1yc3q4xe.fsf at online.no:

> jajvirta at cc.helsinki.fi (Jarno J Virtanen) writes:
> 
>> Wed, 22 May 2002 13:13:06 -0500 Michael Bauers wrote:
>> > 
>> > Why do you say x = []; x.append('a'), but get the length with len(a)
>> ?
>> 
>> > 
>> > Is there a reason for this sort of inconsistency?
>> 
>> why not check the FAQ?
>> 
>>      http://www.python.org/cgi-bin/faqw.py?req=all#6.5
> 
> Yes, but the FAQ seems to be *very* old, it also says that in the
> distant future it may be possible to subclass built in types. 
> 
> I always have to back up in the editor when I am asking an object what
> length it has. Like this (I wanna know the length of object foo):
> foo. "Aw, It's not a method it's a function that calls a method with
> an unsightly name  behind the scenes" back the cursor up and write
> len(foo) instead of foo.len() which would be much more intuitive.
 
think abbout it as an operator. its is written in function syntax because 
+-*/% etc are aleady used.

it has some advantages and it isn't "inconsistent" at all. i think you 
do prefer to write 
>>> 1 + 2
instead of
>>> 1 .__add__(2)
don't you?
(with or without underlines. apropos, "range(3).__len__()" works ;-)

of course you could also say that x[index] is not OO enough and insist on 
having a .get(index) method (i.e. "[1,2,3].__getitem__(2)" now) but then 
you could also take Java and type _much_ more for less readable code.

chris

-- 
Chris <cliechti at gmx.net>