[Python-ideas] Coming up with an alternative to PEP 505's None-aware operators

[Ethan Furman]

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~