[Python-Dev] assignment expressions: an alternative proposal (original) (raw)

Chris Angelico rosuav at gmail.com
Tue Apr 24 18:01:14 EDT 2018

On Wed, Apr 25, 2018 at 7:29 AM, Anthony Flury via Python-Dev <python-dev at python.org> wrote:

On 24/04/18 17:11, Yury Selivanov wrote:

On Tue, Apr 24, 2018 at 12:03 PM, Ethan Furman <ethan at stoneleaf.us> wrote: [..]

But I do write this: def wrapper(func, somevalue): valueIwant = process(somevalue) def wrapped(*args, **kwds): if valueIwant == 42: ... But this pattern is more rare than comparing local variables. That's the point I'm trying to use. Besides, to make it an assignment expression under my proposal you would need to use parens. Which makes it even less likely that you confuse '=' and '=='. Just because you wrap a set of character in parens doesn't mean that you wont potentially mistype what you should type inside the parens. The failure mode of in C : if (a = 3) dosomethingwitha(a); Is Incredibly common even with very experienced developers - so much so that most linters flag it as a likely error, and I think gcc has an option to flag it as a warning - even though it is valid and very occasionally it is useful.

Technically what you have there trips two dodgy conditions, and could produce either warning or both:

  1. Potential assignment where you meant comparison
  2. Condition is always true.

The combination makes it extremely likely that this wasn't intended. It's more dangerous, though, when the RHS is a function call...

Also many developers who come to Python from languages such as C will still place parens around conditionals - this means that a typo which will cause a Syntax Error in current versions, but would cause a potentially subtle bug under your implementation (unless you maintain the rule that you can't rebind currently bound names - which renders the whole idea useless in loops (as already discussed at length).

Yuri, look how many of the python-dev readers have completely misinterpreted this "can't rebind" rule. I think that's a fairly clear indication that the rule is not going to be well understood by anyone who isn't extremely familiar with the way the language is parsed. I hesitate to say outright that it is a bad rule, but that's the lines I'm thinking along.

ChrisA

More information about the Python-Dev mailing list