[Python-ideas] Ruby-style Blocks in Python Idea (alternative)
jan.kanis at phil.uu.nl
Wed Mar 11 01:11:34 CET 2009
On Tue, Mar 10, 2009 at 09:58, spir <denis.spir at free.fr> wrote:
> Le Tue, 10 Mar 2009 01:13:42 +0100,
> Jan Kanis <jan.kanis at phil.uu.nl> s'exprima ainsi:
>> This being python-ideas, I'll also have a go at it.
>> Being someone who does like functional programing when used in limited
>> quantities, I also think multi line lambdas (or blocks, whatever you
>> call them) are a good thing if a good way could be found to embed them
>> into Python. But I don't like the part of tavs proposal of handling
>> them with a magic __do__ function. So what about this slightly
>> modified syntax and semantics:
>> def NAME(ARGS) [as OTHERNAME] with EXPRESSION_CONTAINING_NAME:
>> def callback(param) as result with do_something(with_our(callback),
>> other, args):
>> print("called back with "+param)
>> return foobar(param)
> I like this proposal much more than all previous ones.
> Still, how would you (or anybody else) introduce the purpose, meaning, use of this construct, and its language-level semantics? [This is not disguised critics, neither rethoric question: I'm really interested in answers.]
>From my side, this is more of an idea I had than something I've
thought all the way through, so while I think it looks nice it's not
something I'm 100% committed to. It sprung up in my mind as a slightly
better alternative to tavs blocks proposal.
The language level semantics are easily explained by showing the
equivalent code I gave in my first mail. The purpose and use (and
meaning?) are the same as with tavs original proposal for blocks, and
with those of multistatement lambdas. So I guess a major consideration
is whether someone thinks multiline lambdas are in principle a good
idea (setting aside that they can't be implemented in full generality
non-ugly in the python grammar).
On Tue, Mar 10, 2009 at 17:33, Guido van Rossum <guido at python.org> wrote:
> ... to accomplish something you can already
> do just as easily with a decorator.
Almost the same thing could be done with decorators, the difference
being that the final name the result is assigned to occurs in a weird
place, and that decorators are restricted to one-argument functions.
The first could be solved by allowing an 'as name' clause on
decorators (like Carl Johnson is proposing in the other thread), the
second by e.g. allowing lambdas as decorators so one could do
@lambda f: do_something(with_our(f))
print("called back with "+param)
But I don't really have a specific actual use case for this, so I
think I'll just have to go with Guidos gut feeling, they seem to
work out, usually.
More information about the Python-ideas