On Oct 29, 5:49 pm, "Terry Reedy" <[EMAIL PROTECTED]> wrote:
> I was just reading > |http://docs.python.org/dev/3.0/whatsnew/3.0.html > > which says nothing about such a change, except for one in the opposite > direction: o.next() changes to next(o) which in turn calls o.__next__(), > just as len(o) calls o.__len__() Ugh. A great example of complexification (if there's such a word). > | why not a_string.len()? > > You are free to bypass builtins and call methods directly if you like: > a_string.__len__(). > > But consider rewriting the following: > > def table(func, seq): > return zip(seq, map(func,seq)) > > table(len, ('', (), [])) table(lambda x:x.__len__(), ('',[],())) What was the point again ? > If you *really* want to be super-OO, like functionless OO languages, you > can also call methods instead of using operator symbols, which in effect > are names of builtin functions. > > Instead of a+b, write a.__add__(b). And so on. True, if ones wants to go all the way to, say, Java. Operator overriding though is pretty handy in terms of syntax sugar to give up, especially for expressions that are identical or strongly similar from a familiar context (e.g. maths). This cannot be claimed about len() though. My main problem with len() is not so much the function/method inconsistency, but rather that it doesn't apply to all (or even most) objects. I am much less against, say, getattr(), being a function since it makes sense for all objects. But why len()? At best it's a subjective judgment call of where to draw the line, at worst it's plain inconsistent. And while we're at it, what's the rationale of len() insisting that the return value is >=0 ? That also looks odd in a dynamic language with a "we're all adults here" philosophy and much less hand-holding in areas that matter more (e.g. allowed by default comparisons between instances of different types - at least that's one of the warts Python 3 gets right). George -- http://mail.python.org/mailman/listinfo/python-list
