On 28 February 2018 at 19:41, Chris Angelico <rosuav@gmail.com> wrote:
On Thu, Mar 1, 2018 at 3:30 AM, Paul Moore <p.f.moore@gmail.com> wrote:
Here's another equally untested piece of code:
[(-b + (sqrt(b*b - 4*a*c) as disc)) / (2*a), (-b - disc) / (2*a)]
Yeah, that's a good real world example. And IMO it hides the symmetry between the two expressions, so for me it's a good example of a case where there's a readability *disadvantage* with the proposed syntax.
I haven't dug into the implementation consequences of any of this at global scope. I know what parts of the code I need to look at, but my days have this annoying habit of having only 24 hours in them. Anyone got a bugfix for that? :|
I can give you daylight saving time and a few leap seconds, but that's more of a workaround than a fix :-)
Consider
x = 12 if (1 as x) == 1: def foo(): print(x) # Actually, you'd probably get a "Name used before definition" error here. # Would "global x" refer to x=12 or to the statement-local x (1)? # Would "nonlocal x" refer to the statement-local x? x = 13 return x print(foo())
Yeah, that's going to give UnboundLocalError, because inside foo(), x has been flagged as local. That's independent of the global scope changes.
I'd like to say that "global x" would catch the 12, but until I actually get around to implementing it, I'm not sure.
print(x) print(foo()) print(x)
Anything that executes after the 'if' exits should see x as 12. The temporary variable is completely gone at that point.
So simplifying x = 12 if (1 as x) == 1: def foo(): return x print(foo()) print(foo()) prints 1 12 Personally, I can't work out how to think about that in a way that isn't confusing :-( I gather from what you've said elsewhere that your current implementation uses a hidden name-mangled variable. IIRC, list comprehensions used something similar in the original implementation, but it resulted in weird consequences, and ultimately the implementation switched to a "proper" scoped semantics and implementation. I've no particular reason to think your implementation might suffer in the same way, but understanding the semantics in terms of an "assignment to a hidden variable" bothers me.
The most charitable thing I can say here is that the semantics are currently under-specified in the PEP :-)
Hah. This is why I started out by saying that this ONLY applies inside a function. Extending this to global scope (and class scope; my guess is that it'll behave the same as global) is something that I'm only just now looking into.
And yet, "only works within a function" is IMO an unacceptable limitation - so we need to look into the implications here.
So if, in the "in" expression list, you capture something, that thing will be visible all through the suite. Here's an example:
for item in (get_items() as items): print(item) print(items) print(items)
What actually happens is kinda this:
for item in (get_items() as items_0x142857): print(item) print(items_0x142857) del items_0x142857 print(items)
OK, so that explains why trying to write a closure over a variable introduced via "as" won't work. But I wouldn't want such a renaming to be mandated by the semantics, and I don't know how I'd explain the (implied) behaviour without insisting on a name mangling implementation, so I'm stuck here.
"What the current proof of concept implementation does" isn't useful anyway, but even ignoring that I'd prefer to see what it *does* rather than what it *compiles to*. But what needs to be documented is what the PEP *proposes* it does.
The current implementation matches my proposed semantics, as long as the code in question is all inside a function.
Understood. But I'd like the PEP to fully explain more of the intended semantics, *without* referring to the specific implementation. Remember, PyPy, Jython, IronPython, Cython, etc, will all have to implement it too.
But I can even break expression local names:
x = ((lambda: boom()) as boom) x()
It's possible that the "boom" is just my head exploding, not the interpreter. But I think I just demonstrated a closure over an expression-local name. For added fun, replace "x" with "boom"...
And this is why I am not trying for expression-local names. If someone wants to run with a competing proposal for list-comprehension-local names, sure, but I'm not in favour of that either. Expression-local is too narrow to be useful AND it still has the problems that statement-local has.
I've no idea how that would work under statement-local names either, though. boom = lambda: boom() boom() is just an infinite recursion. I'm less sure that the as version is. Or the alternative form ((lambda: boom()) as boom)() I know you can tell me what the implementation does - but I can't reason it out from the spec.
Thanks for the feedback! Keep it coming! :)
Ask and you shall receive :-)
If I take a razor and cut myself with it, it's called "self-harm" and can get me dinged for a psych evaluation. If I take a mailing list and induce it to send me hundreds of emails and force myself to read them all... there's probably a padded cell with my name on it somewhere.
You know, I'd be okay with that actually. Just as long as the cell has wifi.
lol. Have fun :-) Paul