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

[Kirill Balunov]

What about (| val = get_value(x) |) assignment expression which will be True
if success, and None if not?

So it will be value = f() if (| f = calculate |) else default…The idea is
inspired from C’s assignment, but needs some special treatment for anything
which is False in boolean context.

With kind regards,

-gdg
​

2018-02-16 10:55 GMT+03:00 Nick Coghlan <ncoghlan at gmail.com>:

> On 16 February 2018 at 12:19, rymg19 at gmail.com <rymg19 at gmail.com> wrote:
> > I don't know...to me this looks downright ugly and an awkward special
> case.
> > It feels like it combines reading difficulty of inline assignment with
> the
> > awkwardness of a magic word and the ugliness of using ?. Basically, every
> > con of the other proposals combined...
>
> Yeah, it's tricky to find a spelling that looks nice without being
> readily confusable with other existing constructs (most notably
> keyword arguments).
>
> The cleanest *looking* idea I've come up with would be to allow
> arbitrary embedded assignments to ordinary frame local variables using
> the "(expr as name)" construct:
>
>     value = tmp.strip()[4:].upper() if (var1 as tmp) is not None else None
>
>     value = tmp[4:].upper() if (var1 as tmp) is not None else None
>
>     value = tmp if (var1 as tmp) is not None else tmp if (var2 as tmp)
> is not None else var3
>
>     value = tmp if not math.isnan((var1 as tmp)) else tmp if not
> math.isnan((var2 as tmp)) else var3
>
>     value = f() if (calculate as f) is not None else default
>
>     filtered_values = [val for x in keys if (get_value(x) as val) is not
> None]
>
>     range((calculate_start() as start), start+10)
>     data[(calculate_start() as start):start+10]
>
>     value if (lower_bound() as min_val) <= value < min_val+tolerance else 0
>
>     print(f"{(get_value() as tmp)!r} is printed in pure ASCII as
> {tmp!a} and in Unicode as {tmp}")
>
> 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)
> * 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)
>
> The interaction with compound statements would also be tricky to
> figure out (especially if we went with the "delete after the
> statement" behaviour).
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180216/422a0884/attachment.html>