[Python-Dev] any support for a methodcaller HOF?

Giovanni Bajo rasky at develer.com
Fri Feb 3 17:32:30 CET 2006


Alex Martelli <aleaxit at gmail.com> wrote:

>> use itemgetter and friends but the "correct" way of doing a
>> defferred "x[1]"
>> *should* let you write "x[1]" in the code. This is my main
>> opposition to
>> partial/itemgetter/attrgetter/methodcaller: they allow deferred
>> execution
>> using a syntax which is not equivalent to that of immediate execution.
>
> I understand your worry re the syntax issue.  So what about Michael
> Hudson's "placeholder class" idea, where X[1] returns the callable
> that will do x[1] when called, etc?  Looks elegant to me...

Depends on how the final API looks like. "deffered(x)[1]" isn't that bad,
but "def x: x[1]" still looks clearer as the 'def' keyword immediatly makes
clear you're DEFining a DEFerred function <g> :) Of course we can paint our
bikeshed of whatever color we like, but I'm happy enough if we agree with
the general idea of keeping the same syntax in both deferred and immediate
execution.

There is an also an issue with deferred execution without arguments. By
grepping my code it turned out that many lambda instances are in calls to
assertRaises() (unittest), where I stricly prefer the syntax:

self.assertRaises(TypeError, lambda: int("ABK", 16))

to the allowed:

self.assertRaises(TypeError, int, "ABK", 16)

With the inline def proposal we'd get something along the lines of:

self.assertRaises(TypeError, def(): int("ABK", 16))
self.assertRaises(TypeError, (int("ABK", 16) def))   # it's not lisp,
really, I swear

while I'm not sure how this would get with the placeholder class.
-- 
Giovanni Bajo



More information about the Python-Dev mailing list