9 ms·
The walrus operator provides no benefit here. `my_match` is still in scope in both cases. Python’s `if` statements do not introduce a new scope.
by pansa2 5y ago
The walrus operator provides no benefit here. `my_match` is still in scope in both cases.
Python’s `if` statements do not introduce a new scope.
- DangitBobby 5y agoI know they don't, normally. I really thought that was basically the point of the walrus operator to begin with, that the variable was only in scope for the lifetime of the if statement where it's needed. Huge bummer to find out that's not true.
- dataflow 5y agoLooks like now you're seeing why it's an abomination ;)
- DangitBobby 5y agoIMO the real abomination was already present in the language, which is that if blocks do not introduce new scope. My IDE protects me from the bugs this could easily introduce when I try to use a variable that may not yet be in scope, but it should be detected before runtime. I will readily admit that the walrus operator doesn't do what I thought it did and I have no interest in whatever utility it provides as it exists today.
- dataflow 5y ago> IMO the real abomination was already present in the language, which is that if blocks do not introduce new scope. Definitely. You would think if they're going to undermine decades of their own philosophy, they would instead introduce variable declarations and actually help mitigate some bugs in the process.
- slightwinder 5y agoScoop in python is normally defined by functions/methods, not blocks. The same happens with for-loos and with-blocks. So this is consistent. And this good, because it can be very useful. The exception here are try/except-blocks, where the fetched error is cleaned up after leaving the except-block, for reasons.