The walrus operator is a tired old trope to hate on, but I dont see the point personally. Same goes for the structural pattern matching thing. The tacking on of typing features feels superfluous in a language thats not compiled or even strongly typed.
But for the sake of maximum pendatry let me paste some nitpicky little detail from a somewhat recent syntactic addition:
>>> def f(a, b, /, **kwargs):
... print(a, b, kwargs)
...
>>> f(10, 20, a=1, b=2, c=3)
10 20 {'a': 1, 'b': 2, 'c': 3}
a and b are used in two ways.
Since the parameters to the left of / are not exposed as possible keywords, the parameters names remain available for use in **kwargs
Jesus fucking hell on a tricylce so now i have *'s and /'s showing up in function signatures so someone can prematurely optimize the re-use of variable names without breaking backwards comparability?!
Python is becoming a mockery, dying a death through a thousand little cuts to its ergonomics.
I'm sure you're already aware of this example since it's the canonical one, but to me personally the point is very clear: I use regular expressions all the time and always have to write that little bit of boilerplate, which the walrus operator now lets me get rid of.
Avoiding tedious boilerplate by adding nice features like the walrus operator is precisely what lets us avoid "death through a thousand little cuts to its ergonomics", in my view.
Sure, maybe writing
m = re.match("^foo", s)
if m != None:
...
isn't so bad, but in that case maybe writing
i = 0
while i < len(stuff):
element = stuff[i]
...
i += 1
wouldn't be so bad, and we could get rid of Python's iterator protocol?
I think regex matches might be literally the only use case for := that I come across with any kind of nontrivial frequency, and it's only a minor nuisance at that. Certainly nothing to warrant an entirely new yet different syntax for something we already have.
The iterator protocol is way more general than what you have; it's not remotely comparable.
Regex is just a prominent example of a certain pattern. Depending on work and style, one often has functions which return something, on which in case of a non-empty result you want to do something more. Walrus can shrink the code in data-intensive code quite well from my experience.
The loop can be written using This One Weird Trick that Walruses Hate:
for foo in iter(partial(data.get, "foo"), None):
handle_foo(foo)
So I would only use the walrus operator for the first example (the if statement), which even though it is exactly the same as doing it in two steps just feels nicer as a single step.
It should have been “if … as y” and reused existing syntax. I’ve never seen anyone use the extended variant (multiple assignment) that walrus allows. The extra colons with this and typing makes it look like a standard punctuation-heavy language we sought to avoid in the first place.
AFAIK, the purpose of “/” is so that python-implemented functions can be fully signature-(and, therefore, also type-)compatible with builtins and C-implemented functions that required positional arguments but do not accept those arguments being passed as keyword arguments.
But for the sake of maximum pendatry let me paste some nitpicky little detail from a somewhat recent syntactic addition:
Jesus fucking hell on a tricylce so now i have *'s and /'s showing up in function signatures so someone can prematurely optimize the re-use of variable names without breaking backwards comparability?!Python is becoming a mockery, dying a death through a thousand little cuts to its ergonomics.