Re: Internal Objects: method vs function/procedure vs both

Tim Peters (tim@ksr.com)
Fri, 01 Apr 94 23:32:46 EST

> > > [jim]
> > > Finally, the *real* reason why I entered this thread is to push for
> > > being able to write the equivalent of:
> > >
> > > for i in foo.keys().sort():
> > > ...
> > [tim]
> > Unless you're addicted to dangling-method _syntax_, it's easy to write
> > your own sort _function_ to do this. E.g, ...
> >
> > def sort(sequence):
> > sequence.sort() # precede by "sequence = sequence[:]" for a copying sort
> > return sequence

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