On 02/18/2018 05:57 PM, Nick Coghlan wrote:
On 17 February 2018 at 02:31, Ethan Furman wrote:
On 02/15/2018 11:55 PM, Nick Coghlan wrote:
However, while I think that looks nicer in general, we'd still have to
choose between two surprising behaviours:
* implicitly delete the statement locals after the statement where
they're set (which still overwrites any values previously bound to
those names, similar to what happens with exception clauses)
If we're overwriting locals anyway, don't delete it. The good reason for
unsetting an exception variable doesn't apply here.
* skip deleting, which means references to subexpressions may last
longer than expected (and we'd have the problem where embedded
assignments could overwrite existing local variables)
Odds are good that we'll want/need that assignment even after the immediate
expression it's used in. Let it stick around.
If we want to use a subexpression in multiple statements, then regular
assignment statements already work fine - breaking out a separate
variable assignment only feels like an inconvenience when we use a
subexpression twice in a single statement, and then don't need it any
further.
By contrast, if we have an implicit del immediately after the
statement for any statement local variables, then naming a
subexpression only extends its life to the end of the statement, not
to the end of the current function, and it's semantically explicit
that you *can't* use statement locals to name subexpressions that
*aren't* statement local.
The other concern I have with any form of statement local variables
that can overwrite regular locals is that we'd be reintroducing the
problem that comprehensions have in Python 2.x: unexpectedly rebinding
things in non-obvious ways. At least with an implicit "del" the error
would be more readily apparent, and if we disallow closing over
statement local variables (which would be reasonable, since closures
aren't statement local either), then we can avoid interfering with
regular locals without needing to introduce a new execution scope.
Good points. I see two possibly good solutions:
- don't override existing local variables, implicit del after statement
- override existing local variables, no implicit del after statement
I like the first one better, as it mirrors list comprehensions and is simple to understand. The second one is okay, and
if significantly easier to implement I would be okay with. It's the combination of:
- override existing local variables, implicit del after statement
that I abhor. As I understand it, only try/except has that behavior -- and we have a really good reason for it, and
it's the exception to the general rule, and...
Okay, after further thought I like the second one better. List comps have the outside brackets as a reminder that they
have their own scope, but these "statement local" variables only have internal parenthesis. I still don't like the
third option.
--
~Ethan~
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
