> [jim]
> Ahhh... here you play your real card (IMHO) as to why this issue is
> NBD (No Big Deal) to you.
So near & yet so far <grin>.
> IF you like a functional approach to programming, then the above solves
> your problem.
Not _quite_: it solves my problem period. I'm not a fan of functional
programming.
> IF you like a more object oriented approach, then you want to send
> message methods to objects to do your bidding.
Not a fan of OO programming either.
> 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.
Mine too. But you caricature the case by presenting a pathologically
complicated mixture of styles there -- if "sort(foo.keys())" is beyond
your limit of easy visual comprehension, you're the only person I've ever
met who can't count higher than I can <0.6 grin>.
> My point is that having the ability to stick with a single metaphor is
> very helpful in readability.
If you're in the (bad!) habit of cramming a dozen invocations (of methods
and/or functions) on a single line, I would agree. If you're more
considerate of future readers and generally stick to at most a few
invocations on a single line, I don't think mixing metaphors truly is a
fly in the ointment applied to the boil of obfuscation.
> ...
> 'cause you propose (on would-be equal footing):
> > for i in sort(foo.keys()):
> > ...
You _truly_ believe that's hard to read? If this were a poker game, I'd
raise twenty & call your bluff. Of course we'd have to cut your head
open to find out what you really think, but then this is a high-stakes
game ...
> 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:
> > ...
I prefer the former, but no, the latter's fine too. It's quite clear,
naming "throw-away" intermediate temps is a very effective way to make
complex expressions more readily understandable, and the "inefficiency"
is an illusion (in your preferred "foo.keys().sort()", what do you think
the "foo.keys()" part returns if _not_ a throw-away temp -- albeit an
anonymous one? ditto the ".sort()" part? ).
> ...
> I don't argue for *either* style too heartily,
Then we're halfway to 100% agreement <smile>.
> but I do argue for the ability to use one style of the other
> consistently.
Ya, I do understand the appeal of that. When Guido can't hear me, I
sometimes tell people that while other languages merely support multiple
paradigms, Python forces you to _use_ multiple paradigms <snicker>.
Python is at least "fair" in irritating both functional and OO purists
about equally ... I'm not sure why that doesn't bother me, but strangely
enough it doesn't. I think it's because I have such an easy time _using_
Python to get real work done, so find it hard to get excited about its
putative deficiences.
> If I were god-king-of-the-universe, I'd allow both.
More precisely, I think you mean to say that you'd _build in_ full
support for both styles, as part of the base language. I.e., Python
already _allows_ both (which is why I've often posted little functions to
the list, and Steve's often posted little classes to the list: it's
usually not hard to _fake_ (simulate) either style more purely -- but
you often have to build a little (or a lot) of the supporting machinery
yourself).
> 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.
Believe it or not <smile>, I probably would too. I guess that because
there's at least _one_ builtin way to spell "sort" & "len" & so on, I
figure I've got 95% of what I want, and the other 5% isn't worth carping
about.
can't-count-on-the-elderly-to-lead-the-revolution!-ly y'rs - tim
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp