[Python-Dev] Examples for PEP 572

[Steven D'Aprano]

On Wed, Jul 04, 2018 at 12:10:11AM -0700, Nathaniel Smith wrote:

> Right, Python has a *very strong* convention that each line should
> have at most one side-effect, 

import math, fractions, decimal

(PEP 8 be damned, sometimes, especially in the REPL, this is much 
better than three separate imports.)

values = [mapping.pop(key) for key in (1, 3, 6, 15)]

Admittedly, that's an awfully specific case. But would you really 
re-write that as:

values = [mapping.pop(1)]
values.append(mapping.pop(3)
values.append(mapping.pop(6)
values.append(mapping.pop(15)

just to keep the "one side-effect per line" rule? I wouldn't.

Anyway, since "one side-effect per line" is just a convention, there's 
absolutely no reason why it cannot remain a convention. Don't do this:

values = (x := expensive_func(1, 2))+(y := expensive_func(3, 4)) + x*y

unless you really have to. It's just common sense.

Conventions are good. If they'e enough to stop people writing:

mylist = mylist.sort() or mylist.reverse() or mylist

they'll be good enough to stop people stuffing every line full of 
assignment expressions.



> and that if it does have a side-effect
> it should be at the outermost level.

I don't understand what that means. Do you mean the global scope?



> 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.

I'm not sure that "literally none of us" is quite true, after all the 
code is deterministic and well-defined and surely whoever maintains it 
probably understands it, but even if it were true, I don't see the 
connection between "we don't know the order of operations" and "Python 
has a rule no more than one-side effect per line". Seems a pretty 
tenuous ccomclusion to draw.


> 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.

If you're talking about fixing the scoping issues inside classes, that's 
no longer part of the PEP (although the current version hasn't been 
updated to reflect that). The weirdness of class scopes already exist. 
This might, at worst, make it more visible, but it isn't going to make 
the problem worse.

If you're talking about something else, I can't think of what it might 
be. Can you explain?


> 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, 

Oh, you mean functional languages like Rust, Javascript, and Ruby?

(Or at least, *almost* everything is an expression.)

The functional programming paradigm is a lot more than just "everything 
is an expression", and very much *non*-functional languages like 
Javascript can be designed to treat everything as an expression.



-- 
Steve