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

Quinn Dunkan quinn at bolivar.ugcs.caltech.edu
Sun May 26 14:28:34 EDT 2002


On 22 May 2002 22:59:18 GMT, Michael P. Soulier
<msoulier at mcss.mcmaster.ca_.nospam> wrote:
>    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. 

Not really:

irb(main):001:0> 1 + 2 * 3
7
irb(main):002:0> (1).+(2).*(3)
9
irb(main):003:0> 

... and everyone was annoyed with smalltalk for being consistent that way :)

However, I don't think of 'obj.method' style notation as being the definition
of 'OO'.  It's just a style of syntax.  len(o) is just as 'OO' as o.len(), and
the real question is "why is the syntax different?".

One reasonable answer to that (besides history) is that f(x) and x.f() both
have different notational conveniences.  It's nice to be able to type
map(len, lists) rather than [ a.len() for a in lists ], but it's also nice to
be able to type a.append(x) rather than list.append(a, x).

x.f() tends to be notationally handy where a closure on the first argument is
frequently useful (e.g. a.append).  a.len is not so useful.



More information about the Python-list mailing list