On 30 March 2018 at 06:17, Nick Coghlan <ncogh...@gmail.com> wrote:
> The fact that deep nesting of lexical scopes within an expression is
> almost always going to be an unreadable mess in practice is one of the
> reasons I don't think there's a strong case for either backwards
> compatibility breaks *or* significant increases in the overall
> semantic complexity.
>
> Any sensible coding style is already going to say "Don't do that, it's
> too hard to read", so we're mainly caring about it at all based on our
> own senses of engineering aesthetics and a general dislike of
> implementation details leaking through as user visible semantic
> differences.
OK, cool. That I can completely agree with :-)
>> I do think the current implementation is a pretty good compromise. I'd
>> be reasonably OK with not changing anything in this area. But this
>> discussion was prompted by some of the debates around statement local
>> variables, so "not changing anything" includes, in my mind, "not
>> trying to make statement local variables work" as they interact badly
>> with the current scoping behaviour in this area.
>
> It's specifically lexical closures that lead to things getting weird,
> and that's a key rationale for PEP 572's current recommendation that
> statement locals be completely invisible to nested scopes. Trying to
> have a subscope that isn't visible to the rest of the function it's
> in, while still being visible to nested scopes defined within that
> subscope, seems to lead to sufficient conflicts in reference lifecycle
> and visibility that just using a real nested scope instead ends up
> being preferable.
OK. I can accept your point that lexical closure weirdness is the
reason for PEP 572 preferring to make statement locals ignore nested
scopes. I'm not sure I fully agree, but I can accept it. My point is
that having a construct that introduces new names but makes them
invisible to nested scopes is *also* weird enough to be a problem. As
a result, I think that PEP 572 faces a problem in that it's hit a
problem for which it doesn't have a good solution.
Whether that problem is bad enough to kill the PEP is a matter of
judgement. In my view:
* The benefits of the PEP are marginal
* We haven't yet established a suitably readable syntax (IMO, := is
probably the best suggestion so far, but it still has its problems)
* I remain unconvinced that the PEP improves readability of comprehensions
* Plus the above scoping issue
So for me, the balance is in favour of keeping the status quo. If the
scoping issue could be resolved, the remaining issues are much more
obviously matters of taste and my view on the PEP would move to "not
worth the effort" rather than against.
Paul
PS I should also add that the "just make them assignments" resolution
to PEP 572's scope issues is the only suggestion so far that *doesn't*
have scoping weirdnesses of its own (because it uses existing scoping
mechanisms). The problem with that one is that it's prone to leaking
in ways that I think people are uncomfortable with ("I think" because
I don't have time right now to review the examples given to see for
myself how compelling they are).
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
