[Python-ideas] Inline assignments using "given" clauses

Ryan Gonzalez rymg19 at gmail.com
Fri May 11 15:51:25 EDT 2018

On May 11, 2018 1:45:27 PM Tim Peters <tim.peters at gmail.com> wrote:

> [Brendan Barnwell]
>>> . . . and it's true the latter is a bit more verbose in that case for
>>> little extra benefit.  But when the locally-defined value is used within
>>> a more complicated expression (like the quadratic formula example), I
>>> think readability goes down significantly.  To appease Tim, instead of
>>> using the quadratic formula, though, I will use a more realistic example
>>> that comes up fairly often for me: wanting to do some kind of
>>> normalization on a piece of data for a comparison, while keeping the
>>> unnormalized data for use within the block:
>>>         if some_condition and (stuff:=
>>> get_user_input()).lower().strip().replace('-', ''):
>>> versus
>>>         if some_condition and stuff.lower().strip().replace('-', '') given
>>> stuff = get_user_input():
> [also Brendan]
>>         Ironically I weakened my argument by forgetting to finish my
>> expression there.  I intended that chain of method calls to be used in a
>> comparison to make the surrounding expression more complex.  So revise the
>> above to
>>         if some_condition and (stuff :=
>> get_user_input()).lower().strip().replace('-', '') == existing_value:
>> versus
>>         if some_condition and stuff.lower().strip().replace('-', '') ==
>> existing_value given stuff = get_user_input():
> Even more ironically, to my eyes the original more strongly supported
> your view than the rewrite ;-)
> "given stuff =" stuck out in the original because it was preceded by
> punctuation (a right parenthesis).
> I had to read the rewrite 3 times before i realized you were even
> _using_ "given", because there it's buried between two other names -
> "existing_value given stuff" -  and visually looks more like it's
> actually the 3rd of 4 words (because of the underscore in
> "existing_value").

There are some variants of tanks like 'if let' where the bindings come 
*first*, unlike 'given' where they come last (like Haskell's 'where').

> Of course that would have been obvious in a Python-aware editor that
> colored "given" differently, but as-is I found the original easy to
> read but the rewrite a puzzle to decode.

Well, you've partly explained the reason: our eyes are drawn to what sticks 
out. In this case, the := stuck out in a section heavy on black letters. In 
a proper editor, it may even be the other way around: they tend to 
highlight keywords in a stronger manner (like bolding) than operators.

> Similarly, in the rewritten assignment expression spelling, it's
> obvious at a glance that the test is of the form
>     some_condition and  some_messy_expression == existing_value
> but in the rewritten "given" sample that's obscured because
> "existing_value" not only doesn't end the statement, it's not even
> followed by punctuation.  Of course coloring "given" differently would
> remove that visual uncertainty too.  For a dumb display, I'd write it
>    if some_condition and (
>        stuff.lower().strip().replace('-', '') == existing_value) given
> stuff = get_user_input():
> instead (added parens so that "existing_value" and "given" are
> separated by punctuation).
> _______________________________________________
> 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/

More information about the Python-ideas mailing list