[Python-Dev] Examples for PEP 572
steve at pearwood.info
Wed Jul 4 11:56:11 EDT 2018
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)]
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
> 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
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,
(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
More information about the Python-Dev