On Wed, Jul 4, 2018 at 2:16 PM Tim Peters <tim.pet...@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 "if"). 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. Yury _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
