On Thu, Oct 13, 2011 at 6:01 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On Fri, Oct 14, 2011 at 7:01 AM, Greg Ewing <greg.ewing@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@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas