[Python-Dev] PEP 572: Assignment Expressions

[Chris Angelico]

On Sat, Apr 21, 2018 at 7:12 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 21 April 2018 at 03:30, Chris Angelico <rosuav at gmail.com> wrote:
>> There's that word "readability" again. Sometimes I wish the Zen of
>> Python didn't use it, because everyone seems to think that "readable"
>> means "code I like".
>
> Readability is subjective, yes. But it's not the same as "liking". If
> a significant number of people say that they find a piece of code hard
> to read/understand, then that's a problem. It's all too easy to say
> "you don't have to write code like that", but as someone who has been
> a maintenance programmer for his whole career, I can tell you that
> people don't always have that luxury. And supporting code that's
> written in a language that prioritises "readability" (whatever that
> may mean) is a much easier task than supporting code written in a
> language that doesn't. There's a reason far fewer people write systems
> in Perl these days, and it's not because you can't write clear and
> maintainable code in Perl...

But you haven't answered anything about what "readable" means. Does it
mean "if I look at this code, I can predict what dis.dis() would
output"? Or does it mean "this code clearly expresses an algorithm and
the programmer's intent"? Frequently I hear people complain that
something is unreadable because it fails the former check. I'm much
more interested in the latter check. For instance, this line of code
expresses the concept "generate the squares of odd numbers":

[x*x for x in range(100) if x % 2]

But it doesn't clearly express the disassembly. Is that a problem? Are
list comprehensions a bad feature for that reason? I don't think so.

ChrisA