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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
