On 16 February 2018 at 12:19, rym...@gmail.com <rym...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/