[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] Examples for PEP 572

On Wed, Jul 4, 2018 at 2:16 PM Tim Peters <tim.peters at gmail.com> wrote:
> [Yury Selivanov]
> > Wow, I gave up on this example before figuring this out (and I also
> > stared at it for a good couple of minutes).  Now it makes sense.  It's
> > funny that this super convoluted snippet is shown as a good example
> > for PEP 572.  Although almost all PEP 572 examples are questionable.
> And another who didn't actually read the PEP Appendix.  See my reply just before this one:  yes, the Appendix gave that as a good example, but as a good example of assignment-expression ABUSE.  The opposite of something desirable.
> I've never insisted there's only one side to this, and when staring at code was equally interested in cases where assignment expressions would hurt as where they would help.  I ended up giving more examples where they would help, because after writing up the first two bad examples in the Appendix figured it was clear enough that "it's a bad idea except in cases where it _obviously_ helps".
> Same way,  e.g., as when list comprehensions were new, I focused much more on cases where they might help after convincing myself that a great many nested loops building lists were much better left _as_ nested loops.  So I looked instead for real-code cases where they would obviously help, and found plenty.
> And I'm really glad Python added listcomps too, despite the possibility of gross abuse ;-)

Thank you for the clarification, Tim.  I agree, list comprehensions
can indeed be abused and we all see that happening occasionally.
However, assignment expressions make it easy (almost compelling) to
push more logic even to simple comprehensions (with one "for" / one

You probably understand why most core devs are irritated with the PEP:
the majority thinks that the potential of its abuse can't be compared
to any other Python syntax.  It's sad that the PEP doesn't really
address that except saying "This is a tool, and it is up to the
programmer to use it where it makes sense, and not use it where
superior constructs can be used."  Well, to those of use who routinely
review code written by people who aren't proficient Python coders
(read most people working at Google, Facebook, Dropbox, Microsoft, or
really any company) this argument is very weak.

In other words: I'm looking forward to reviewing clever code written
by clever people.  Spending extra time arguing if a snippet is
readable or not should be fun and productive, right? :)  Disabling :=
as a company-wide policy will probably be the only way out.