On Mon, Dec 14, 2020 at 5:57 PM Paul Sokolovsky <pmis...@gmail.com> wrote: > > But that's what the question was about, and why there was the intro! > Let's please go over it again. Do you agree with the following: > > a + (b + c) <=> t = b + c; a + t > > ? > > Where "<=>" is the equivalence operator. I do hope you agree, because > it's both basis for evaluation implementation and for refactoring > rules, and the latter is especially important for line-oriented > language like Python, where wrapping expression across lines requires > explicit syntactic markers, which some people consider ugly, so there > should be clear rules for splitting long expressions which don't affect > there semantic.
It really depends on what you mean by "equivalent". For instance, I'm sure YOU will agree that they have the semantic difference of causing an assignment to the name 't'. Additionally, Python will evaluate a before b and c in the first example, but must evaluate b and c, add them together, and only after that evaluate a. So, no, they aren't entirely equivalent. Obviously, in many situations, the programmer will know what's functionally equivalent, but the interpreter can't. Clarify what you mean by equivalence and I will be able to tell you whether I agree or not. (It's okay if your definition of equivalent can't actually be described in terms of actual Python code, just as long as you can explain which differences matter and which don't.) ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/AV6WOKO6NFIDI63FMTVMEF7UOEFHI7LH/ Code of Conduct: http://python.org/psf/codeofconduct/
