The situation is a bit more complicated than that. PEP-3099 explicitly rejected the possibility for such operator (There will be no alternative binding operators such as :=.) for which Guido explicitly said, literally, "brr". It was a case closed thing that got stirred back up for little gain. It's not a with statement, it's not async, it is a minor addition that saves one or two lines of code and makes the teaching of the language more complex, because it's an operator that does two things at once, and makes C programmers used to be scared of if conditions with typos in assignments very uncomfortable (e.g. = vs ==). As far as I am concerned, I teach it as the "that is" operator. IOW I say "match that is re.search(yada yada)", but as far as I am concerned, while I might use it, I don't like it.
Thanks for that reference. Didn't know that PEP. I don't like := either, and probably use it very little, but at the end of day nobody is forced to use it, and if the community dislike it that much, you won't find it very often in code.
I hear that argument a lot, and by that logic, we should just implement every conceivable thing, and if the community doesn't like it, it won't be used, so what's the harm? The harm is, the language loses its focus. We have seen this before, e.g. with Java and C# where over the years, too many things got implemented that did the same ting, which slows down production because the programmer might be accustomed to doing things a particular style, but is working with code using a different style. Eventually, the languages got streamlined again, but if you have a codebase using the styles that got cut out, you have two options, either rewrite the old codebase to use the new uniform style or stay on an old version, both with big cons.
@@jskallebak Since the argument is that it will lose focus if we implement "every conceivable thing" and just don't use it, then we can also go for the other extreme and argue against the idea of adding no conceivable thing and say it will lose flexibility and opportunity to improve. After it was implemented, the walrus didn't disrupt python. Some people use it, some don't.
All joking aside, I like the walrus operator. It's a simple and elegant solution for certain expensive calls and it lets me translate C/C++ code (with assingments in conditions) in a logical 1:1 fashion to Python. Moreover, if you don't need it, you don't have to use it. Thanks for this!
Why is this always the argument? It's a reduction of 50% code! so it's great right? Yes, I guess if my codebase were 2 lines of code. In reality, it's more like a 5-10% reduction in lines at best, but the lines also get longer and more complex and will eventually have to be broken into multiple lines anyways.
This " := " is a Collator. And does exactly what it means. Collator definition/, to gather or arrange things in their proper sequence (the pages of a report, the sheets of a book, the pages of several sets of copies, etc.). Then too the first part of the name linked to col in colon.
Not really. Can you do f(x := y*y, x) in C? You can't. Can you do, if (x := f(y)) { print(y, x); } in C? You can't. (Sure, there are some GCC extensions to make it possible to do something similar probably. In C, even your example doesn't work: You need to write: int c; while ((c = getchar()) > 0) { f(c); }, which does pollute the outer scope. The := is a declaration of a new variable, assignment and an expression on itself. The c = f(), in C is assignment and expression. In Python, = is not expression, it is a part of assignment statement. (c = f()) is not a valid expression, nor you can do a = (b = 3). The a = b = 3, will work in Python, but not because b = 3 is an expression, but because of how the assignment statement grammar is defined. It is more like a let keyword in Ocaml.
pycon: can you phrase your question as a question.
First person: I'ma make a statement.
Talking about operator starts at 4:05
This is a too small benefit in expense of readability. Won't use it.
15:33 Well, I think we all learned a lesson today.
PEP 572 -- Assignment Expressions
Me gusto la charla. Me agradó ver cómo funciona la toma de decisiones en el core de Python
The situation is a bit more complicated than that. PEP-3099 explicitly rejected the possibility for such operator (There will be no alternative binding operators such as :=.) for which Guido explicitly said, literally, "brr". It was a case closed thing that got stirred back up for little gain. It's not a with statement, it's not async, it is a minor addition that saves one or two lines of code and makes the teaching of the language more complex, because it's an operator that does two things at once, and makes C programmers used to be scared of if conditions with typos in assignments very uncomfortable (e.g. = vs ==). As far as I am concerned, I teach it as the "that is" operator. IOW I say "match that is re.search(yada yada)", but as far as I am concerned, while I might use it, I don't like it.
Thanks for that reference. Didn't know that PEP. I don't like := either, and probably use it very little, but at the end of day nobody is forced to use it, and if the community dislike it that much, you won't find it very often in code.
I hear that argument a lot, and by that logic, we should just implement every conceivable thing, and if the community doesn't like it, it won't be used, so what's the harm?
The harm is, the language loses its focus. We have seen this before, e.g. with Java and C# where over the years, too many things got implemented that did the same ting, which slows down production because the programmer might be accustomed to doing things a particular style, but is working with code using a different style. Eventually, the languages got streamlined again, but if you have a codebase using the styles that got cut out, you have two options, either rewrite the old codebase to use the new uniform style or stay on an old version, both with big cons.
@@jskallebak Since the argument is that it will lose focus if we implement "every conceivable thing" and just don't use it, then we can also go for the other extreme and argue against the idea of adding no conceivable thing and say it will lose flexibility and opportunity to improve. After it was implemented, the walrus didn't disrupt python. Some people use it, some don't.
All joking aside, I like the walrus operator. It's a simple and elegant solution for certain expensive calls and it lets me translate C/C++ code (with assingments in conditions) in a logical 1:1 fashion to Python. Moreover, if you don't need it, you don't have to use it. Thanks for this!
That was a great talk. Thank you, Justin.
Brilliant speaker!
Why is this always the argument? It's a reduction of 50% code! so it's great right? Yes, I guess if my codebase were 2 lines of code. In reality, it's more like a 5-10% reduction in lines at best, but the lines also get longer and more complex and will eventually have to be broken into multiple lines anyways.
one of the most important improvments of the language - it will be everywhere, look at JS!
If f(x) is so damn expensive! Why not cache the result?!
Cause you might not needed ever again.
This " := " is a Collator. And does exactly what it means.
Collator definition/, to gather or arrange things in their proper sequence (the pages of a report, the sheets of a book, the pages of several sets of copies, etc.). Then too the first part of the name linked to col in colon.
Pascal had this and we never had any trouble. It's almost intuitive.
Is this the bdfl destructor or the steering committe constructor operator? I'm not sure...it's doing two things at the same time.
It's like "while ((c = getchar()) > 0)" in C
Not really. Can you do f(x := y*y, x) in C? You can't. Can you do, if (x := f(y)) { print(y, x); } in C? You can't. (Sure, there are some GCC extensions to make it possible to do something similar probably. In C, even your example doesn't work: You need to write: int c; while ((c = getchar()) > 0) { f(c); }, which does pollute the outer scope. The := is a declaration of a new variable, assignment and an expression on itself. The c = f(), in C is assignment and expression. In Python, = is not expression, it is a part of assignment statement. (c = f()) is not a valid expression, nor you can do a = (b = 3). The a = b = 3, will work in Python, but not because b = 3 is an expression, but because of how the assignment statement grammar is defined.
It is more like a let keyword in Ocaml.
Almost a bit of Lisp for...
Only as python 3.8
This walrus operator is disgusting. Too much is happening in one line. It actually obscures the code.
The "while" example is the only nice one
python should have private and public option and java should learn something
from python