[Python-Dev] Don't assign to a variable used later in the expression (original) (raw)
Ivan Pozdeev vano at mail.mipt.ru
Wed Jul 4 20:40:36 EDT 2018
- Previous message (by thread): [Python-Dev] Don't assign to a variable used later in the expression
- Next message (by thread): [Python-Dev] Don't assign to a variable used later in the expression
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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. 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
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20180705/db696f2a/attachment-0001.html>
- Previous message (by thread): [Python-Dev] Don't assign to a variable used later in the expression
- Next message (by thread): [Python-Dev] Don't assign to a variable used later in the expression
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]