why no 'length' method in sequences ?

[Alex Martelli]

Richard Gruet wrote:

> 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.

"Entities must not be multiplied without necessity", no -- but in this case
the necessity, or rather the opportunity, IS there, as I showed.

Everything IS "consistently object-oriented" -- polymorphism is the
principal magic of object-orientedness.  There would be substantial
loss of power without measurable conceptual simplification if Python
had no methods (how would I store a bound-method just as any
other callable then?) or if it had no functions (serious polymorphism
loss).

Besides, I doubt your objection is whole-hearted.  What language
except some Lisp-like ones has ONLY one way to invoke code?  I
don't hear you complaining that Python has operators too -- yet
they differ in nothing but syntax-sugar from the builtin functions
that you appear to dislike so.  How is x**y so different from pow(x,y)
that you accept one and not the other -- syntax-sugar strictly --
and fail to see that x.pow(y) as the sole alternative would be UTTER
disaster?  pow(x, y) offers extras too -- if it can it calls x.__pow__(y),
else y.__rpow__(x).  Just like cmp(x, y) can call various different
special methods on x OR y depending on what works.

We can't have operators for _every_ functionality that could benefit
from such treatment, as I hope is obvious.  Defining everything as
method would be a HORRIBLE loss.


> 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 ? 

Sorry, but to me it sure seems that way.  How would this mythical 'sequence'
implement your desired method in a way that's correct for all sequences?!
I see no sensible alternative to letting each sequence class determine what 
"length" means to it.

> 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'.

Yes, and?  What do you think type object implements, exactly?

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

And I'm expressing my own feelings in return -- and motivating them, as
I see you're trying to motivate yours.  My feelings are that you (like most
people, it seems at times) "can't judge a book by its cover": instead of
trying to understand WHY a designer has set things up in a certain way,
and only forming judgment when you do have a decent grasp of that,
you seem to be snapping to "feelings" based on superficial impressions.

You may ASK "why", but you don't really WANT to know -- as evidenced
by your reaction when the question is answered, it appears to me.

If you want to program productively and understand things, Python and
this newsgroup can help.  If you prefer to "express feelings" based on
superficial syntax-sugar issues, I suspect they can help much less.


Alex