20 ms·

Walrus operator looks like a great addition, not too much syntax sugar for a common pattern. Why were folks arguing about it?

joshuamorton 7y ago
It's not that common. There's 1 place where its useful imo (comprehensions to avoid duplicate calls), but even that can be handled case by case, and it certainly isn't a common thing.
- theli0nheart 7y ago
  Disagree. In my experience (albeit, not very long, been writing Python since 2007 or so), assigning to a value and checking for truthiness is a very common pattern.
  - noname120 7y ago
    Very common pattern, confusing nonetheless. It does two different things at once where traditionally Python is explicit and only does one thing at once.
    - nerdponx 7y ago
      This is probably the one argument against it that I agree with: I don't actually like it when I see it in other languages!
- coldtea 7y ago
  It's extremely common. I've had to use a workaround for that every time I've tested a regular expression match that I wanted to process for example. Also problematic in comprehensions...
hdfbdtbcdg 7y ago
Because it goes against 20 years of the principles behind the language.
- coldtea 7y ago
  Actually it doesn't violate any of the principles behind the language. It could have been there from day one, like tons of others things added later and now totally loved. I should know, I've worked with Python for 22 years...
  - sametmax 7y ago
    Guido disagrees and rejected the idea multiple time in the last 2 decades. I think he worked on Python for a long time too :) This feature is kind of a symbol, the first real decision of the transition between the bdfl and the next era. I'm not worried about it, but yes, it was really against python core principles.
    - shaklee3 7y ago
      See other replies. Guido was for the operator.
      - sametmax 7y ago
        See my other replies as well.
    - orf 7y ago
      That’s an impressively incorrect history of the operator. The zen of Python is not a binding constitution. It does not mean nothing can be added if there is some way to do it already, especially if that way improves things. It’s no more “going against the principles” than f-strings where, and they turned out just great.
    - ben509 7y ago
      Quoth the PEP[1], Guido changed his mind when he found proof that coders would write redundant (and expensive) code to avoid using a separate line to construct a temporary variable. So one might argue that a principle of python is that the language is dictated by how people read and write rather than the other way around... it's pretty hard to say what principles are "core" when they all conflict and you have to weigh various tradeoffs. [1]: https://www.python.org/dev/peps/pep-0572/#the-importance-of-real-code https://www.python.org/dev/peps/pep-0572/#the-importance-of-...
adjkant 7y ago
I write a good deal of python and I can't think of a line of code that I would use it for besides the while loop on a non-iterable data source, which is such a once in a blue moon case. As mentioned by others, the operator invites more ways to do the same thing, which is not what Python has been viewed as being about.
- orangecat 7y ago
  Victor Stinner made a demonstration pull request using the walrus operator in the standard library where it makes sense. On balance it removes several hundred lines and often makes the code much clearer, e.g. https://github.com/python/cpython/pull/8122/files#diff-78e8ea3354eac632b8978306b0275826L1425 https://github.com/python/cpython/pull/8122/files#diff-78e8e...
  - mixmastamyk 7y ago
    The argument was about mostly about the syntax. In the link above, the "as" keyword would work with (very close to) all of those lines and arguably more readable.
- drexlspivey 7y ago
  I do this all the time: x = function_that_might_return_none() if x: do_stuff
sametmax 7y ago
It's the most controversial feature ever introduced because it goes against a lot of python culture and philosophy. All in all the debate has been heated and long, but it has been decided that the python community will use it intelligently and rarely, but that when it matters, it can help a lot. I'm against this feature, while I was pro f-string. However, I'm not too worried about missuse and cultural shift because I've seen 15 years of this show going on and I'm confident on it's going to be indeed tagged as "risky, use it knowing the cost" by everybody by the time 3.8 gets mainstream.
- andrewshadura 7y ago
  Oh come on, it doesn't.
  - sametmax 7y ago
    My metric for this is to put some of my freshest student in front of a code and see how they deal with it. How easily can they understand it ? How easily can they write it ? Debug it ? They are most of the time a fantastic indicator of the cognitive load a feature will add in prod. Because of course a feature doesn't exist in a vacuum, it's always in a more complex context. So what's easy to understand for a student will be alright for a pro in the complexity of real life engineering. And I found the opposite to hold quite often as well. I haven't tried the walrus on them yet, but I'm pretty sure of the result.
    - nerdponx 7y ago
      I for one predict that the new operator will appear very sparingly, in while loops and code golf competitions. There are already so many complicated semantics about mutability, iteration, bytes/strings, scoping, et al. And yet somehow a tiny piece of syntax that finally lets us stop writing "while true/break" is the big pain point?
      - upofadown 7y ago
        Excess complexity almost always comes in small increments...
deleted 7y ago
[deleted]
coldtea 7y ago
Change aversion.
chrisseaton 7y ago
I don't know how you read it - 'if x is assigned the value y'? Most other things in Python can just be read out loud.
- thaumasiotes 7y ago
  Read it "if y" - that's what's being tested. The walrus simultaneously names the value being tested so you can refer to it within the condition; it's sort of the inverse of Perl code using $_. So instead of if (do_something()) { act_on($_); } you have if placeholder := do_something(): act_on(placeholder) But when reading aloud, however you'd read the perl will flow as more natural english. "If the string contains z, do something with it". If you really want to read the Python as it's written, it corresponds to the second of these sentences: - If the substring from 3 to 5 is "fg", crash. - If variable_name, the substring from 3 to 5, is "fg", crash.
  - txcwpalpha 7y ago
    >Read it "if y" - that's what's being tested. Once way to test if this works is to take the code, read it aloud, and then use the read-aloud version to rewrite the code. If you don't have a high degree of certainty that you end up with the same code, something has failed along the way. In this case, if I take "if x:= y()" and read it aloud as "if y", I think the vast majority of people would translate that to code as "if y():", which isn't the same thing.
    - thaumasiotes 7y ago
      You will end up with the same code under two conditions: 1. You read more than one line of code. 2. Executing the code in the conditional more than once doesn't matter. If you meet those two assumptions, then the reading I suggested will transform this if x := y(): act_on(x) into this if y(): act_on(y()) which is, in fact, the same thing.
      - txcwpalpha 7y ago

joshuamorton 7y ago

It's not that common. There's 1 place where its useful imo (comprehensions to avoid duplicate calls), but even that can be handled case by case, and it certainly isn't a common thing.

theli0nheart 7y ago
Disagree. In my experience (albeit, not very long, been writing Python since 2007 or so), assigning to a value and checking for truthiness is a very common pattern.
- noname120 7y ago
  Very common pattern, confusing nonetheless. It does two different things at once where traditionally Python is explicit and only does one thing at once.
  - nerdponx 7y ago
    This is probably the one argument against it that I agree with: I don't actually like it when I see it in other languages!
coldtea 7y ago
It's extremely common. I've had to use a workaround for that every time I've tested a regular expression match that I wanted to process for example. Also problematic in comprehensions...

hdfbdtbcdg 7y ago

Because it goes against 20 years of the principles behind the language.

coldtea 7y ago
Actually it doesn't violate any of the principles behind the language. It could have been there from day one, like tons of others things added later and now totally loved. I should know, I've worked with Python for 22 years...
- sametmax 7y ago
  Guido disagrees and rejected the idea multiple time in the last 2 decades. I think he worked on Python for a long time too :) This feature is kind of a symbol, the first real decision of the transition between the bdfl and the next era. I'm not worried about it, but yes, it was really against python core principles.
  - shaklee3 7y ago
    See other replies. Guido was for the operator.
    - sametmax 7y ago
      See my other replies as well.
  - orf 7y ago
    That’s an impressively incorrect history of the operator. The zen of Python is not a binding constitution. It does not mean nothing can be added if there is some way to do it already, especially if that way improves things. It’s no more “going against the principles” than f-strings where, and they turned out just great.
  - ben509 7y ago
    Quoth the PEP[1], Guido changed his mind when he found proof that coders would write redundant (and expensive) code to avoid using a separate line to construct a temporary variable. So one might argue that a principle of python is that the language is dictated by how people read and write rather than the other way around... it's pretty hard to say what principles are "core" when they all conflict and you have to weigh various tradeoffs. [1]: https://www.python.org/dev/peps/pep-0572/#the-importance-of-real-code https://www.python.org/dev/peps/pep-0572/#the-importance-of-...

adjkant 7y ago

I write a good deal of python and I can't think of a line of code that I would use it for besides the while loop on a non-iterable data source, which is such a once in a blue moon case. As mentioned by others, the operator invites more ways to do the same thing, which is not what Python has been viewed as being about.

orangecat 7y ago
Victor Stinner made a demonstration pull request using the walrus operator in the standard library where it makes sense. On balance it removes several hundred lines and often makes the code much clearer, e.g. https://github.com/python/cpython/pull/8122/files#diff-78e8ea3354eac632b8978306b0275826L1425 https://github.com/python/cpython/pull/8122/files#diff-78e8e...
- mixmastamyk 7y ago
  The argument was about mostly about the syntax. In the link above, the "as" keyword would work with (very close to) all of those lines and arguably more readable.
drexlspivey 7y ago
I do this all the time: x = function_that_might_return_none() if x: do_stuff

sametmax 7y ago

It's the most controversial feature ever introduced because it goes against a lot of python culture and philosophy. All in all the debate has been heated and long, but it has been decided that the python community will use it intelligently and rarely, but that when it matters, it can help a lot. I'm against this feature, while I was pro f-string. However, I'm not too worried about missuse and cultural shift because I've seen 15 years of this show going on and I'm confident on it's going to be indeed tagged as "risky, use it knowing the cost" by everybody by the time 3.8 gets mainstream.

andrewshadura 7y ago
Oh come on, it doesn't.
- sametmax 7y ago
  My metric for this is to put some of my freshest student in front of a code and see how they deal with it. How easily can they understand it ? How easily can they write it ? Debug it ? They are most of the time a fantastic indicator of the cognitive load a feature will add in prod. Because of course a feature doesn't exist in a vacuum, it's always in a more complex context. So what's easy to understand for a student will be alright for a pro in the complexity of real life engineering. And I found the opposite to hold quite often as well. I haven't tried the walrus on them yet, but I'm pretty sure of the result.
  - nerdponx 7y ago
    I for one predict that the new operator will appear very sparingly, in while loops and code golf competitions. There are already so many complicated semantics about mutability, iteration, bytes/strings, scoping, et al. And yet somehow a tiny piece of syntax that finally lets us stop writing "while true/break" is the big pain point?
    - upofadown 7y ago
      Excess complexity almost always comes in small increments...

deleted 7y ago

[deleted]

coldtea 7y ago

Change aversion.

chrisseaton 7y ago

I don't know how you read it - 'if x is assigned the value y'? Most other things in Python can just be read out loud.

thaumasiotes 7y ago
Read it "if y" - that's what's being tested. The walrus simultaneously names the value being tested so you can refer to it within the condition; it's sort of the inverse of Perl code using $_. So instead of if (do_something()) { act_on($_); } you have if placeholder := do_something(): act_on(placeholder) But when reading aloud, however you'd read the perl will flow as more natural english. "If the string contains z, do something with it". If you really want to read the Python as it's written, it corresponds to the second of these sentences: - If the substring from 3 to 5 is "fg", crash. - If variable_name, the substring from 3 to 5, is "fg", crash.
- txcwpalpha 7y ago
  >Read it "if y" - that's what's being tested. Once way to test if this works is to take the code, read it aloud, and then use the read-aloud version to rewrite the code. If you don't have a high degree of certainty that you end up with the same code, something has failed along the way. In this case, if I take "if x:= y()" and read it aloud as "if y", I think the vast majority of people would translate that to code as "if y():", which isn't the same thing.
  - thaumasiotes 7y ago
    You will end up with the same code under two conditions: 1. You read more than one line of code. 2. Executing the code in the conditional more than once doesn't matter. If you meet those two assumptions, then the reading I suggested will transform this if x := y(): act_on(x) into this if y(): act_on(y()) which is, in fact, the same thing.
    - txcwpalpha 7y ago