[Python-ideas] Long Live PEP 3150 (was: Re: Statement local functions and classes (aka PEP 3150 is dead, say 'Hi!' to PEP 403))

[Nick Coghlan]

On Mon, Oct 17, 2011 at 10:30 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sun, 16 Oct 2011 17:16:40 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>>     # Embedded assignments in if statements
>>     if match is not None given match=re.search(pattern, text):
>>         # process match
>>     else:
>>         # handle case where regex is not None
>>
>>     # Embedded assignments in while loops
>>     while match is not None given match=re.search(pattern, text):
>>         # process match
>>     else:
>>         # handle case where regex is not None
>
> Urk. What is the use case for these? Save one line of code but actually
> type *more* characters?
>
> "given" doesn't look like a very pretty notation to me, honestly.
> Apparently you're looking for a way to allow assignments in other
> statements but without admitting it (because we don't want to lose
> face?...).

They're throwaway ideas - there's a reason the PEP itself is
restricted to simple statements.

> Also:
>
> sorted_data = sorted(data, key=sort_key) given:
>    def sort_key(item):
>        return item.attr1, item.attr2
>
> isn't light-weight compared to anonymous functions that other languages
> have.
> The whole point of anonymous functions in e.g. Javascript is that
> embedding them in another statement or expression makes it a very
> natural way of writing code. The "given" syntax doesn't achieve this
> IMO; it forces you to write two additional keywords ("given" and "def")
> and also write twice a function name that's totally useless - since you
> can't reuse it anyway, as pointed out by Raymond.
>
> I'm -1 on that syntax.

If we accept the premise that full featured anonymous functions have
their place in life (and, over the years, I've been persuaded that
they do), then Python's sharp statement/expression dichotomy and
significant leading whitespace at the statement level severely limit
our options:

1. Adopt a syntax that still names the functions, but uses those names
to allow forward references to functions that are defined later in a
private indented suite (this is the route I've taken in PEP 3150).
This is based on the premise that the real benefit of anonymous
functions lies in their support for top down thought processes, and
that linking them up to a later definition with a throwaway name will
be less jarring than having to go back to the previous line in order
to fill them in while writing code, and then skip over them while
reading code to get to the line that matters, before scanning back up
to loop at the operation details.

2. Adopt a symbolic syntax to allow a forward reference to a trailing
suite that is an implicit function definition somewhat along the lines
of Ruby block, only with Python-style namespace semantics (this
approach was soundly demolished in the overwhelmingly negative
reactions to PEP 403 - the assorted reactions to PEP 3150 have been
positively welcoming by comparison)

3. Continue the trend of giving every Python statement an equivalent
expression form so that lambda expressions become just as powerful as
named functions (we've gone a long way down that road already, but
exception handling and name binding are sticking points. One of my
goals with PEP 3150 is actually to *halt* that trend by providing a
"private suite" that allows the existing significant whitespace syntax
to be embedded inside a variety of statements)

4. Add a non-whitespace delimited syntax that allows suites to be
embedded inside expressions at arbitrary locations (I believe "from
__future__ import braces" answers that one)

5. Just accept that there are some styles of thought that cannot be
expressed clearly in Python. Developers that don't like that can
either suck it up and learn to live with writing in a style that
Python supports (which is, admittedly, not a problem most of the time)
or else find another language that fits their brains better. That's a
perfectly reasonable choice for us to make, but we should do it with a
clear understanding of the patterns of thought that we are officially
declaring to be unsupported.

That last option, of course, is the status quo that currently wins by
default. If anyone can think of additional alternatives outside those
5 options, I'd love to see a PEP :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia