On 17 April 2018 at 14:07, Paul Moore <p.f.moore at gmail.com> wrote: > On 17 April 2018 at 14:01, David Mertz <mertz at gnosis.cx> wrote: >> Strongly agree with Nick that only simple name targets should be permitted >> (at least initially). NONE of the motivating cases use more complex targets, >> and allowing them encourages obscurity and code golf. > > I also agree. Originally I would have said why not allow them, it's a > potentially useful generalisation. But Nick's examples pretty clearly > demonstrate that there are a lot of unclear edge cases involved, and > even though "prevent people writing ugly code" is explicitly stated as > a non-goal in the PEP, that doesn't mean it's OK to allow an obvious > bug magnet with no clear use cases. I should also point out that I remain -0 on this proposal (I'd already said this on python-ideas, but I should probably repeat it here). For me, the use cases are mostly marginal, and the major disadvantage is in having two forms of assignment. Explaining to a beginner why we use a := b in an expression, but a = b in a statement is going to be a challenge. The fact that the PEP needs a section covering all the style guide warnings we feel are needed seems like it's a warning bell, too. Paul
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4