On 11 April 2018 at 16:22, Nick Coghlan <ncogh...@gmail.com> wrote:
> Similar to my suggestion above, you may also want to consider making
> this example a filtered comprehension in order to show the proposal in
> its best light:
> results = [(x, y, x/y) for x in input_data if (y := f(x) )]
Agreed, this is a *much* better motivating example.
>> This could be used to create ugly code!
>> So can anything else. This is a tool, and it is up to the programmer to use
>> where it makes sense, and not use it where superior constructs can be used.
> This argument will be strengthened by making the examples used in the
> PEP itself more attractive, as well as proposing suitable additions to
> PEP 8, such as:
> 1. If either assignment statements or assignment expressions can be
> used, prefer statements
> 2. If using assignment expressions would lead to ambiguity about
> execution order, restructure to use statements instead
+1 on explicitly suggesting additions to PEP 8. Bonus points for PEP 8
additions that can be automatically checked by linters/style checkers
(For example "avoid chained assignment expressions").
Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/