On Fri, Oct 14, 2011 at 2:28 PM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
On Fri, Oct 14, 2011 at 1:47 AM, Greg Ewing <greg.ewing@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