3 ms·
> Yes doing the walrus operator inside brackets works. Yes of course it's going to be doing weird things. Is this really surprising to anyone? Yes, it is in fa
by conistonwater 6y ago
> Yes doing the walrus operator inside brackets works. Yes of course it's going to be doing weird things. Is this really surprising to anyone?
Yes, it is in fact extremely surprising that an expression does something different based on surrounding context. It would be as if expr had one meaning but it you called f(expr) it had another. Saying that you're using it unexpectedly doesn't really address the issue of language design.
It reminds me of Matlab's idea (a long time ago) that f(i) is either a function call or an array access at index i, but you will not know for sure until you've evaluated f, so expressions like f(i)(j) end up being just weird. There is a certain amount of logic that you are fully justified in expecting from a language.
> It's not what that operator is for.
If your idea is that an operator is free to do whatever, once it's outside its predicted situation, then I can see how that's technically correct based on the language spec, but it just seems like a very weird way to just a language design.
I think if you think that some of those examples have no legitimate uses at all you'd then have no problem saying that they should be syntax errors but are accepted anyway, that it's just a bug in the parser, that it accepts too much.
I also do not see how this is anti-python, I think you are being unfair to the author.
- Doxin 6y ago> It is in fact extremely surprising that an expression does something different based on surrounding context It isn't doing anything different though. Compare: >>> a:=1 1 >>> (1, 2) (1, 2) >>> (a:=1, 2) (1, 2) The thing that's confusing people here isn't even the walrus operator, it's tuple syntax. > If your idea is that an operator is free to do whatever, once it's outside its predicted situation No it's not. But clearly an operator can never do an operation it isn't defined to do. is and == are different operators and they do different things. > I think if you think that some of those examples have no legitimate uses at all They do have legitimate uses, but purposefully obfuscating the context around what the code is doing is hardly the fault of the language. > I also do not see how this is anti-python, I think you are being unfair to the author. Yeah on further thought it really isn't anti-python, but articles like the OP do tend to get linked in anti-language posts, which is probably what got me a bit annoyed about the article. No fault of the author.