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

[Jim Jewett]

On Fri, Oct 14, 2011 at 2:28 PM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
> On Fri, Oct 14, 2011 at 1:47 AM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>> Nick Coghlan wrote:

>>> So, keep the PEP 3150 syntax, but don't make the inner suite special
>>> aside from the out of order execution?

>   given:
>       a = 1
>       b = 2
>   def f(a=given.a, b=given.b):
>       ...

A few years ago, I would have liked this (except for the awkward
repetition of given.*), because it would have felt like the function
was cleaning up after itself.

Even now, I like it, because the extra indentation make it clear that
a and b group with f.  Today, I do (or fail to do) that with vertical
whitespace.

But I'm not sure it answers the original concerns.

> ...   First you'll write that part you care about.  Then
> you'll write the dependent code _above_,

It is precisely that going-back-up that we want to avoid, for readers
as well as for writers.

> Also, the in-order given statement is easy to following when reading
> code, while the post-order one is less so.

I like a Table of Contents.  Sometimes I like an outline.  I can
follow a bottom-up program, but it is usually better if I can first
see "Here's the main point", *followed*by* "Here's how to do it."

> 1. How would decorators mix with given clauses on function/class
> definitions?  (maybe disallow?)

I would assume that they work just like they do now -- put them on the
line right before the definition, at the same indent level.  That
would be after the given clause semantically, and also literally if
the given clause happens before the def.

Having decorators come outside the given clause would be a problem,
because the given statements don't always return anything, let alone
the right function.

Banning decorators would seem arbitrary enough that I would want to
say "hmm, this isn't ready yet."

> 2. How could you introspect the code inside the given clause? (same as
> code in a function body?)

Either add a .given node to the function object, or treat it like any
other module-level (or class-level) code outside a function.

>    Python's demand that the function be named and introduced
>    before the operation that needs it breaks the developer's flow
>    of thought.

I think of this a bit like C function prototypes and header files.
You get used to the hassle of having to repeat the prototypes, but it
is still a bad thing.  Having the prototypes as a quick Table Of
Contents or Index, on the other hand, is a good thing.

> big advantage of the post-order given statement, that I see, is that
> you can do a one-liner:

Nah; if it really is a one-liner, then moving the definition up a line
isn't that expensive.  The big advantage is when something is a level
of detail that you don't want to focus on yet, but it is also
(textually) big enough to cause a mental interruption.

-jJ