On 05.07.2018 3:40, Ivan Pozdeev via Python-Dev wrote: > On 05.07.2018 2:29, Nathaniel Smith wrote: >> On Wed, Jul 4, 2018 at 4:10 PM, Ivan Pozdeev via Python-Dev >> <python-dev at python.org> wrote: >>> On 04.07.2018 10:10, Nathaniel Smith wrote: >>>> 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. >> This would rule out all the comprehension use cases. > Only those outside of the outermost iterable. Scratch this line, it was from an earlier edit of the letter. I invalidate this myself further on. >> I'd be fine with that personally. Reading through the PEP again I see >> that there are more examples of them than I previously realized, >> inside the semantics discussion and... well, this may be a personal >> thing but for me they'd all be better described as "incomprehensions". >> But, nonetheless, the comprehension use cases are supposed to be a >> core motivation for the whole PEP. > > Far from it. If/while, too. Any construct that accepts an expression > and uses its result but doesn't allow to insert an additional line in > the middle qualifies. >> Also, some of the main arguments >> for why a full-fledged := is better than the more limited alternative >> proposals rely on using a variable on the same line where it's >> assigned (e.g. Tim's gcd example). So I don't see this recommendation >> getting any official traction within PEP 572 or PEP 8. > That's actually a valid use case! > In the aforementioned example, > if (diff := x - x_base) and (g := gcd(diff, n)) > 1: > return g > the variable `diff' doesn't exist before, so there's no confusion > which value is used. > > > Okay, I stay corrected: > > _Do not recommend *changing* a variable that is used later in the > expression._ > > I.e. the variable should not exist before assignment (or effectively > not exist -- i.e. the old value should not be used). > > > E.g., good: > > [ rem for x in range(10) if rem := x%5 ] > > bad: > > [ sum_ for x in range(10) if (sum_ := sum_ + x) % 5 ] # good > luck figuring out what sum_ will hold > > >> Of course you're free to use whatever style rules you prefer locally – >> python-dev has nothing to do with that. >> >> -n >> > > -- > Regards, > Ivan > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru -- Regards, Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20180705/fb09395f/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