[Python-ideas] explicitation lines in python ?
ncoghlan at gmail.com
Mon Jul 12 15:32:51 CEST 2010
> That said, my suggested semantics still have the desired effect in
> your use case, since your expression does not contain a name binding
> operation, so it makes no difference whether name binding would have
> been handled via a return value (your suggestion, which I tried and
> failed to implement last time) or via nonlocal name bindings (my
> suggestion this time around).
Bleh, I just remembered why nonlocal semantics won't work for this use
case: nonlocal only looks at function namespaces, so class and module
namespaces don't count. That behaviour would be unacceptable for a
where clause implementation.
So this suggestion going anywhere post-moratorium is firstly dependent
on someone figuring out how to properly split name binding operations
across the two namespaces (such that the values are generated in the
inner scope, but assigned in the outer scope).
As an example of the kind of thing that actually makes this a nightmare:
x = b[index] = value where:
index = calc_target_index()
value = calc_value()
It turns out that name binding is only part of the problem though.
Variable *lookup* actually shares one of the problems of nonlocal name
binding: it skips over class scopes, so the inner scope can't see
class level names. Generator expressions and most comprehensions (all
bar 2.x list comprehensions) already have this problem - at class
scope, only the outermost iterator can see names defined in the class
body, since everything else is in a nested scope where name lookup
skips over the class due to the name lookup semantics that were
originally designed for method implementations (i.e. before we had
things like generator expressions that implicitly created new scopes).
It took a while for all these evil variable referencing semantic
problems to come back to me, but they're the kind of thing that needs
to be addressed before a where clause proposal can be taken seriously.
As I noted in my last message, I *did* try to implement this years ago
and I now remember that the only way I can see it working is to define
a completely new means of compiling a code object such that variable
lookup and nonlocal namebinding can "see" an immediately surrounding
class scope (as well as outer function scopes) and still fall back to
global semantics if the name is not found explicitly in the symbol
table. I believe such an addition would actually be beneficial in
other ways, as I personally consider the current name lookup quirks in
generator expressions to be something of a wart and these new
semantics for implicit scopes could potentially be used to fix that
(although perhaps not until Py4k). However, adding such lookup
semantics is a seriously non-trivial task (I've been working with the
current compiler since I helped get it ready for inclusion in 2.5 back
when it was still on the ast-compiler branch and I'm not sure where I
would even start on a project like that. It wouldn't just be the
compiler either, the VM itself would almost certainly need some
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-ideas