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

[Eric Snow]

On Thu, Oct 13, 2011 at 6:01 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Fri, Oct 14, 2011 at 7:01 AM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>> Withdrawing PEP 3150 altogether seems like an over-
>> reaction to me. A lot of its problems would go away
>> if the idea of trying to make the names local to the
>> suite were dropped. That part doesn't seem particularly
>> important to me -- we manage to live without the
>> for-loop putting its variable into a local scope,
>> even though it would be tidier if it did.
>
> So, keep the PEP 3150 syntax, but don't make the inner suite special
> aside from the out of order execution?
>
> While that would work, it still feels overly heavy for what I consider
> the primary use case of the construct:
>
>    sorted_list = sorted(original, key=key_func) given:
>        def key_func(item):
>            return item.attr1, item.attr2
>
> The heart of the problem is that the name 'key_func' is repeated
> twice, encouraging short, cryptic throwaway names. Maybe I'm worrying
> too much about that, though - it really is the out of order execution
> that is needed in order to let the flow of the Python code match the
> way the developer is thinking about their problem.
>
> I'll note that the evolution from PEP 3150 (as shown above) to PEP 403
> went as follows:
>
> 1. Make the inner suite a true anonymous function with the signature
> on the header line after the 'given' clause. Reference the function
> via '@' since it is otherwise inaccessible.
>
>    sorted_list = sorted(original, key=@) given (item):
>        return item.attr1, item.attr2
>
> 2. Huh, that 'given' keyword doesn't scream 'anonymous function'. How
> about 'def' instead?
>
>    sorted_list = sorted(original, key=@) def (item):
>        return item.attr1, item.attr2
>
> 3. Huh, that looks almost exactly like decorator prefix syntax. And
> the callable signature is way over on the RHS. What if we move it to
> the next line?
>
>    sorted_list = sorted(original, key=@)
>    def (item):
>        return item.attr1, item.attr2
>
> 4. We may as well let people add a name for debugging purposes, and
> it's less work to just make it compulsory to match existing syntax. By
> keeping the shorthand symbolic reference, we get the best of both
> worlds: a descriptive name for debugging purposes, a short local name
> for ease of use.
>
>    sorted_list = sorted(original, key=@)
>    def key_func(item):
>        return item.attr1, item.attr2
>
> 5. Well, the parser won't like that and it's backwards incompatible
> anyway. We need something to flag the prefix line as special. ':' will
> do.
>
>    :sorted_list = sorted(original, key=@)
>    def key_func(item):
>        return item.attr1, item.attr2
>
> 6. Keywords are better than symbols, so let's try that instead
>
>    postdef sorted_list = sorted(original, key=def)
>    def key_func(item):
>        return item.attr1, item.attr2
>
> PEP 403 really is just an extension of the principles behind
> decorators at its heart, so I think it makes sense for those semantics
> to have a decorator-style syntax.

Yeah, I was explaining the idea to someone today and the decorator
connection clicked.  It seems like this new syntax is giving you
temporary access to the anonymous object on the frame stack, almost
like a limited access to a special "frame scope".  The decorator
syntax provides this by passing that anonymous object in as the
argument to the decorator.  Is that an accurate perspective or did I
misunderstand?

-eric

> If we want to revert back to using
> an indented suite, than I think it makes more sense to go all the way
> back to PEP 3150 and discuss the relative importance of "out of order
> execution" and "private scope to avoid namespace pollution".
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>