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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4