On Fri, Oct 14, 2011 at 1:01 PM, Jim Jewett <jimjjewett@gmail.com> wrote:
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.
I see what you mean. And when you are interacting with an object from an outer scope then it doesn't matter where the object was defined, as long as it happened execution-wise before you go to use it. However, in the same block, the object you are going to use must be defined _above_, since execution flows down. For example, a module will have "if __name__ == "__main__" at the bottom, if it has one. I guess I'm just used to code generally following that same pattern, even when not semantically necessary. In-order just _seems_ so natural and easy to understand. But on the other hand, I was able to figure out other out-of-order syntax in Python... Perhaps I simply need to adjust to out-of-order syntax. Out-of-order doesn't feel nearly as natural to me, but that may only be the consequence of my experience and not reflect its value. Presently I can only defer to others with more experience here to make a case for or against it. In the meantime, the in-order variant seems to me to be the better choice.
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.
Code as a table of contents...hadn't considered it. It's an interesting idea. For large modules I've seen it mostly done in the module docstring, rather than in code. When I need a table of contents for some code I'll usually use dir(), help(), dedicated documentation, or docstrings directly (in that order). When I code I usually keep the number of objects in any given block pretty small, thus it's easy to scan through. But with other (equally/more valid) coding styles than mine (and other languages) I can see where code as a table of contents at the beginning would be helpful.
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.
That mental interruption is definitely to be avoided. In those cases I typically factor that code out into a function. Then the high-level execution is obvious in one place. I'm not seeing how a given statement (of either variant) would be helpful there; and I don't see how it would be an interruption in places I would use it. Thanks for the insights. I definitely want to get on the same page (either way) with those promoting the post-order given statement. I'm glad that Nick wrote PEP 403 because it's gotten me thinking about this. Regardless of the variant, I think the idea of one-off anonymous namespaces is worth figuring out. -eric
-jJ