On 04.07.2018 10:10, Nathaniel Smith wrote: > On Tue, Jul 3, 2018 at 11:07 PM, Serhiy Storchaka<storchaka at gmail.com> wrote: >> 04.07.18 00:51, Chris Angelico пише: >>> On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka<storchaka at gmail.com> >>> wrote: >>>> I believe most Python users are not >>>> professional programmers -- they are sysadmins, scientists, hobbyists and >>>> kids -- >>> [citation needed] >> I don't understand what citation do you need. >> >>>> In particularly mutating and >>>> non-mutating operations are separated. The assignment expression breaks >>>> this. >>> [citation needed] >> In Python the assignment (including the augmented assignment) is a >> statement, del is a statement, function and class declarations are >> statements, import is a statement. Mutating methods like list.sort() and >> dict.update() return None to discourage using them in expressions. This a >> common knowledge, I don't know who's citation you need. > Right, Python has a *very strong* convention that each line should > have at most one side-effect, and that if it does have a side-effect > it should be at the outermost level. > > I think the most striking evidence for this is that during the > discussion of PEP 572 we discovered that literally none of us – > including Guido – even *know* what the order-of-evaluation is inside > expressions. In fact PEP 572 now has a whole section talking about the > oddities that have turned up here so far, and how to fix them. Which > just goes to show that even its proponents don't actually think that > anyone uses side-effects inside expressions, because if they did, then > they'd consider these changes to be compatibility-breaking changes. Of > course the whole point of PEP 572 is to encourage people to embed > side-effects inside expressions, so I hope they've caught all the > weird cases, because even if we can still change them now we won't be > able to after PEP 572 is implemented. I may have a fix to this: Do not recommend assigning to the variable that is used later in the expression. And to facilitate that, do not make any strong guarantees about evaluation order -- making any such attempt a gamble. I immediately saw those "total := total + item" as odd but couldn't quite point out why. Now I see: it ignores the whole augmented assignment machinery thing, which will make people demand that next. Making this a discouraged case will diminish valid use cases and lower the need for that. > Some people make fun of Python's expression/statement dichotomy, > because hey don't you know that everything can be an expression, > functional languages are awesome hurhur, but I think Python's approach > is actually very elegant. Python is unapologetically an imperative > language, but even we dirty imperative programmers can agree with the > functional fanatics that reasoning about side-effects and sequencing > is hard. One-side-effect-per-line is a very elegant way to keep > sequencing visible on the page and as easy to reason about as > possible. > > Or as Dijkstra put it: "our intellectual powers are rather geared to > master static relations and that our powers to visualize processes > evolving in time are relatively poorly developed. For that reason we > should do (as wise programmers aware of our limitations) our utmost to > shorten the conceptual gap between the static program and the dynamic > process, to make the correspondence between the program (spread out in > text space) and the process (spread out in time) as trivial as > possible." > > It's very disheartening that not only is PEP 572 apparently going to > be accepted, but as far as I can tell neither the text nor its > proponents have even addressed this basic issue. > > -n > -- Regards, Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20180705/6a092141/attachment.html>
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