4 ms·

Could you give a concrete example of how the walrus operator is worse for the language? I know you've admitted that this is a rant but without anything to back

Could you give a concrete example of how the walrus operator is worse for the language? I know you've admitted that this is a rant but without anything to back it up, it isn't much interesting to read. As for the switch statement, I'm inclined to agree although if we see `switch` as syntactic sugar for a bunch of other conditional statements, then what makes it a more important candidate for inclusion than the walrus operator? Thanks in advance, I'm genuinely curious to know.

FakeComments 7y ago
Not GP, but — What makes if statements and loop statements more useful than goto statements? Switch is a powerful abstraction over chained and/or nested if statements, in much the same way other constructs are abstractions over goto. A programming language is for humans to read — and switch statements greatly enhance comprehension. While other languages use := for assignment, and perhaps there’s arguments that’s better in the face of typos, Python doesn’t in general — and I don’t see the utility in adding a second way to do assignment. The use cases of the walrus operator are useful, but they’re just cases of assignment in many languages; a second sometimes used assignment operator is not.
marcosdumay 7y ago
The walrus operator has very clear problems once you start to use the assigned variable at the same line it receives a new value. That's not really relevant on practice, since nobody does it, but it moves a language from a philosophy of simple semantics into one where people are ok with undefined behavior or a pile of exceptional cases. This change does smell really bad for people that have seen it before, so those tend to overreact and start complaining that the sky is falling. Specifically on the case of Python, it used to promise simple semantics a long while ago. This changed at some point, and the semantics were already complex before the walrus operator. With the operator added, semantics becomes a bit more complex, but this is not a main feature of the language anymore, so it's not a big change. Yet, pattern matching would have a very small semantic footprint, and would solve the same kinds of problems (despite having a very different nature), but was very vocally rejected without any of the deep analysis that went into the walrus operator. It looks like this happened because they would have a very large syntactic footprint, basically completely changing the appearance of the language, but the process left the people that focused on semantics lost, without understanding what was happening.
robomartin 7y ago
> Could you give a concrete example of how the walrus operator is worse for the language? Because it isn't necessary? All you have to do is extend the syntax to now allow the one-and-only assignment operator to function in other places, for example, in an "if" or "for" statement and you are done. Anything else can be taken care of with parenthesis. For more examples of how I don't see any applicable ambiguity, see my reply below to a different question: https://news.ycombinator.com/item?id=21426133 https://news.ycombinator.com/item?id=21426133 I mean, to me this is like adding a wing to the back of a four door family car. It's useless complexity. We want to reduce complexity, not increase it. BTW, I read through the entire PEP [0] and still find no way to answer this basic question in favor of the walrus operator: What's wrong with simply extending the functionality of the existing assignment operator? I looked through the examples and mentally made the change. I can't see any need for the new operator. Case in point, this is one of the examples given in the PEP: Current: reductor = dispatch_table.get(cls) if reductor: rv = reductor(x) else: reductor = getattr(x, "__reduce_ex__", None) if reductor: rv = reductor(4) else: reductor = getattr(x, "__reduce__", None) if reductor: rv = reductor() else: raise Error( "un(deep)copyable object of type %s" % cls) Improved: if reductor := dispatch_table.get(cls): rv = reductor(x) elif reductor := getattr(x, "__reduce_ex__", None): rv = reductor(4) elif reductor := getattr(x, "__reduce__", None): rv = reductor() else: raise Error("un(deep)copyable object of type %s" % cls) My version, after declaring that "=" can now be used this way: if reductor = dispatch_table.get(cls): rv = reductor(x) elif reductor = getattr(x, "__reduce_ex__", None): rv = reductor(4) elif reductor = getattr(x, "__reduce__", None): rv = reductor() else: raise Error("un(deep)copyable object of type %s" % cls) Why do we absolutely need the walrus operator again? And yet I go back to the "Current" pre-walrus code and have to ask: What is wrong with it? It's clear, very clear. And, nothing whatsoever in this logic is changing at the microprocessor level because of the use of the walrus operator. Even with we do not extend "=" to be able to use it in extended form, there is nothing whatsoever wrong with the original code. This basic structure has been used for decades in myriad languages. Not sure why there's a need to reinvent a wheel for basically zero gain. Extend "=" so it works in a few places, sure, that might clean-up code, but walrus? C'mon.

FakeComments 7y ago

Not GP, but — What makes if statements and loop statements more useful than goto statements? Switch is a powerful abstraction over chained and/or nested if statements, in much the same way other constructs are abstractions over goto. A programming language is for humans to read — and switch statements greatly enhance comprehension. While other languages use := for assignment, and perhaps there’s arguments that’s better in the face of typos, Python doesn’t in general — and I don’t see the utility in adding a second way to do assignment. The use cases of the walrus operator are useful, but they’re just cases of assignment in many languages; a second sometimes used assignment operator is not.

marcosdumay 7y ago

The walrus operator has very clear problems once you start to use the assigned variable at the same line it receives a new value. That's not really relevant on practice, since nobody does it, but it moves a language from a philosophy of simple semantics into one where people are ok with undefined behavior or a pile of exceptional cases. This change does smell really bad for people that have seen it before, so those tend to overreact and start complaining that the sky is falling. Specifically on the case of Python, it used to promise simple semantics a long while ago. This changed at some point, and the semantics were already complex before the walrus operator. With the operator added, semantics becomes a bit more complex, but this is not a main feature of the language anymore, so it's not a big change. Yet, pattern matching would have a very small semantic footprint, and would solve the same kinds of problems (despite having a very different nature), but was very vocally rejected without any of the deep analysis that went into the walrus operator. It looks like this happened because they would have a very large syntactic footprint, basically completely changing the appearance of the language, but the process left the people that focused on semantics lost, without understanding what was happening.

robomartin 7y ago

> Could you give a concrete example of how the walrus operator is worse for the language? Because it isn't necessary? All you have to do is extend the syntax to now allow the one-and-only assignment operator to function in other places, for example, in an "if" or "for" statement and you are done. Anything else can be taken care of with parenthesis. For more examples of how I don't see any applicable ambiguity, see my reply below to a different question: https://news.ycombinator.com/item?id=21426133 https://news.ycombinator.com/item?id=21426133 I mean, to me this is like adding a wing to the back of a four door family car. It's useless complexity. We want to reduce complexity, not increase it. BTW, I read through the entire PEP [0] and still find no way to answer this basic question in favor of the walrus operator: What's wrong with simply extending the functionality of the existing assignment operator? I looked through the examples and mentally made the change. I can't see any need for the new operator. Case in point, this is one of the examples given in the PEP: Current: reductor = dispatch_table.get(cls) if reductor: rv = reductor(x) else: reductor = getattr(x, "__reduce_ex__", None) if reductor: rv = reductor(4) else: reductor = getattr(x, "__reduce__", None) if reductor: rv = reductor() else: raise Error( "un(deep)copyable object of type %s" % cls) Improved: if reductor := dispatch_table.get(cls): rv = reductor(x) elif reductor := getattr(x, "__reduce_ex__", None): rv = reductor(4) elif reductor := getattr(x, "__reduce__", None): rv = reductor() else: raise Error("un(deep)copyable object of type %s" % cls) My version, after declaring that "=" can now be used this way: if reductor = dispatch_table.get(cls): rv = reductor(x) elif reductor = getattr(x, "__reduce_ex__", None): rv = reductor(4) elif reductor = getattr(x, "__reduce__", None): rv = reductor() else: raise Error("un(deep)copyable object of type %s" % cls) Why do we absolutely need the walrus operator again? And yet I go back to the "Current" pre-walrus code and have to ask: What is wrong with it? It's clear, very clear. And, nothing whatsoever in this logic is changing at the microprocessor level because of the use of the walrus operator. Even with we do not extend "=" to be able to use it in extended form, there is nothing whatsoever wrong with the original code. This basic structure has been used for decades in myriad languages. Not sure why there's a need to reinvent a wheel for basically zero gain. Extend "=" so it works in a few places, sure, that might clean-up code, but walrus? C'mon.