why no 'length' method in sequences ?

[Richard Gruet]

Alex

Well, this is a very impressive and learned argumentation and I don't doubt
that using operators and built-in functions offer a better polymorphism.
I just meant that to my human eyes, it is easier to memorize when everything
is consistently object oriented and there are only methods (like in Java -
and I prefer Python to Java :-), or the contrary, only functions. Then I
have not to remember which functions are methods and which ones are
built-in. I think this is because a mixed model is more complicated than a
non-mixed one.

And BTW, people would not to have implement any __len__ method if all the
sequence types would derive from a common ancestor (sequence), in which the
(in)famous method would be implemented. Would it be completely nonsensical ?
I have been told that starting from 2.2, new style classes (including most
built-in types) all derive from a common base class 'object'.

NB: I am NOT setting a dispute, but just expressing my feeling from a user
perspective.

Richard


"Alex Martelli" <aleax at aleax.it> wrote in message
news:zwFv8.36236$vF6.1097456 at news2.tin.it...
> Richard Gruet wrote:
>
> > Hi all
> >
> > I wonder why there is no 'length' (or 'len') method - or attribute - in
> > the sequences types. Having to use the built-in function len() doesn't
> > sound very Object-Oriented to me. I understand that the built-in
function
> > len() must be kept for compatibility reasons, but why not to add also
the
> > method len() to the sequence types ? Is there a reason ?
>
> I would be a silly burden on people who want to implement a sequence
> type, to make them define a method called len that is an exact synonym
> for the existing special method __len__.  And it would be an intolerable
> burden, conceptually and in terms of performance, if looking up an
> attribute named 'len' performed strange black-magic contortions (even
> worse if those contortions were specialized for only the cases in which
> said attribute is meant to be called -- remember Python does not draw
> deep distinctions between attributes meant to be called, and others).
>
> It may not SOUND "very Object-Oriented", but having special methods
> "clothed" by means of built-ins and operators is a clever and subtle
> set-up, as I tried explaining in the other post to this thread.  And
Python
> has always preferred the steak to the sizzle, whenever choice was needed:
> part of what makes it such a great language.
>
>
> Alex
>