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

[Nick Coghlan]

Eric Nieuwland wrote:
> On 4 feb 2006, at 3:18, Nick Coghlan wrote:
>> All I'm suggesting is that a similarly inspired syntax is worth
>> considering when it comes to deferred expressions:
>>
>>    def f(x):
>>      return x*x
>>
>> => f = (x*x def (x))
> 
> It's not the same, as x remains free whereas in g = [x*x for x in seq] x 
> is bound.

That's like saying "it's not the same because '(x*x def (x)' creates a 
function while '(x*x for x in seq)' creates a generator-iterator". Well, 
naturally - if the expression didn't do something different, what would be the 
point in having it?

The parallel I'm trying to draw is at the syntactic level, not the semantic. 
I'm quite aware that the semantics will be very different ;)

> Yours is
> 
> f = lambda x: x*x
> 
> and it will die by Guido hand...

In the short term, probably. I'm hoping that the progressive accumulation of 
workarounds like itemgetter, attrgetter and partial (and Alex's suggestion of 
'methodcaller') and the increasing use of function arguments for things like 
sorting and the itertools module will eventually convince Guido that deferring 
expressions is a feature that needs to be *fixed* rather than discarded entirely.

But until the BDFL is willing to at least entertain the notion of fixing 
deferred expressions rather than getting ridding of them, there isn't much 
point in writing a PEP or a patch to tweak the parser (with the AST in place, 
this is purely a change to the parser front-end - the AST and code generation 
back end don't need to be touched).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org