Ahhh... here you play your real card (IMHO) as to why this issue is
NBD (No Big Deal) to you. IF you like a functional approach to
programming, then the above solves your problem. IF you like a more
object oriented approach, then you want to send message methods to
objects to do your bidding. I think it is much easier to read either:
x.h().g().f().e().d().c()
(which *I* think is real easy) or:
c(d(e(f(g(h(x))))))
(which isn't too bad, but makes my eyes bug a bit at the end) than to
read:
c(e(g(x.h()).f()).d())
which is beyond my visual comprehension.
My point is that having the ability to stick with a single metaphor is
very helpful in readability. I guess you don't mind the last one :-\,
'cause you propose (on would-be equal footing):
>
> for i in sort(foo.keys()):
> ...
>
and alternately you don't mind the inefficiency of forcing use of
throw-away temps, and the addition of two lines of code in :-(:
> keys = foo.keys()
> keys.sort()
> for i in keys:
> ...
>
> You'd have a hard time making a serious argument that either of these
> alternatives is _difficult_, and arguments based on style are a hard
> sell.
>
> Tim Peters tim@ksr.com
I don't argue for *either* style too heartily, but I do argue for the
ability to use one style of the other consistently.
If I were god-king-of-the-universe, I'd allow both. This would mean
that internal types would have both len() methods AND would work as
args to the function len(). I'd also provide a *method* for internal
types (like lists) that sort the contents, and returns self (or a copy
thereof for immutable types) so OO kinda' folks can stick with their
metaphor.
Jim
Jim Roskind
408-982-4469
jar@infoseek.com