[Python-ideas] Proposal for function expressions

[Chris Perkins]

On Wed, Jul 15, 2009 at 4:27 AM, Paul Moore<p.f.moore at gmail.com> wrote:
>
> The important principle that George quoted:
>
> 2009/7/15 George Sakkis <george.sakkis at gmail.com>:
>> Thanks, this was it. The important part is Guido's quote "any solution
>> that embeds an indentation-based block in the middle of an expression
>> is unacceptable", so it's basically a design judgement, not an
>> implementation constraint.
>
> is key here - keep blocks and expressions distinct. Future proposals
> should keep that in mind.

I think you may be misinterpreting - note Guido's use of the word
"middle".  That is precisely why I proposed allowing blocks only at
the _end_ of expressions, and not in the middle.  OTOH, I may just be
projecting the interpretation of that statement that suits me best. :)

To answer some of the other points that have been raised:

Steven:
>Did I understand correctly that you prohibited using `if`, `while` and
>other block statements inside the do block?
No, you misunderstood. What you are thinking of is the fact that the
test expression in an if block, or a while block, cannot have an
appended block. A block is really just syntactic sugar for a def - it
lacks only a name, and the ability to be decorated. It can have a
docstring, it can be a generator, etc.

Steven:
>Personally, the only time I've ever missed the ability to create
>multi-line lambdas was when I had a series of code blocks like this:
>
>try:
>   BLOCK
>except exception, e:
>   process_error(e)
>
>where the BLOCK was different in each one, and I really wanted to factor
>out the common code into a function "process" and pass each BLOCK as an
>argument:
>
>while condition:
>   process(BLOCK1)
>process(BLOCK2)
>if something:
>   process(BLOCK3)
>
>sort of thing.

Do you mean something like this?
def safely(body):
    try:
        body()
    except exception, e:
        process_error(e)

while condition:
    safely() do:
        BLOCK1
safely() do:
    BLOCK2
if something:
    safely() do:
        BLOCK3

I don't claim that a pattern like that will work in all cases, because
the body of the blocks have their own local scope. If you need to set
a variable in the enclosing scope, it might not do what you want (but
we do have "nonlocal" now, so that helps).

Carl:
>That said, I have to insist that what you've proposed as
>
>f() do:
>   BLOCK
>
>be written instead as
>
>f(&) do:
>   BLOCK
>
>Just magically inserting the block as the last argument to a call is
>something I hate about Ruby

Sure, that's OK with me. I also expected the argument that the empty
parentheses after "do" should not be optional, for symmetry with def,
and that's fine with me to. I was just trying to keep the syntax as
"lightweight" as possible for the simplest cases.

Stephen:
>Some people feel that giving names to a cognitive chunk is an
>essential part of the process of chunking.  They are made
>uncomfortable, and often confused, by code which is named only by its
>own source (aka "blocks").  Others don't feel that way.  The former
>oppose this kind of proposal strongly, the latter support it more or
>less actively.

Agreed, and I do have a slight nagging worry that blocks could be
abused, in that people could use them in cases where a named function
would be better (and I agree that there will always be many such
cases). But then I remember that "we're all adults here", and that in
practice people can just as easily, and often do, give useless names
to small functions, and then I don't worry about it so much anymore.

Carl:
>If it's the lack of function names and docstrings

Python 2.7a0 (trunk, Jul 12 2009, 07:54:12) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> def f(b): return b.__doc__
...
>>> f() do:
...     "Look, ma, I'm a docstring!"
...
"Look, ma, I'm a docstring!"
>>>

Overall, I think we're at the point where most of us agree that this
is a very subjective matter, and it comes down to taste. Guido has a
well-recorded history of saying (paraphrasing) "just write a def with
a name and quit whining!", so I suppose the odds for this proposal are
not great. But I have certainly enjoyed the discussion, so thanks to
everyone who has participated.

Chris Perkins