Thank you.
Yes, evidence regarding existing usage is undeniable.
So yes, the analysis and PEPs painted fairly grim picture.
And at the time I didn’t question it much and just took time to “learn what I should remember NOT to do”.
However, with this approach, by now, I could not remember how it works.
So I made an attempt to find out “how I CAN make use of it”.
And the result is that the picture I have now is much more balanced.
First of all, as I said, it is quite simple.
Secondly, github search:
/except BaseException\:\n\s+pass(\n\s+){1,5}return/ Language:Python
2.6K files where except BaseException could be replaced with finally. A lot of false positives (github doesn’t do back references on global search), but a lot of true positives as well.
(only couple of dozens of hits for continue/break though)
It is difficult to construct absolute beginner example which is useful as most of cases where BaseException is useful are interfaces/plugins where errors are being suppressed/ignored for the sake of not interrupting runtime. And either delayed to be treated later or default is returned as a valid alternative.
So alternative would be to acknowledge it as valid construct.
And those who wish can turn-off the linter rule.
Cons:
- Explicit is better than implicit - undeniable.
- If it doesn’t become more popular, education gap might not go away.
Pros:
- No need to condemn this construct. Effort has been made and it works well.
- Saves up to 10% of runtime.
finally doesn’t have the same performance overhead as except.
After spending a bit of time with it, I quite like it and would likely use it - there is nothing too bad about it and makes my code a bit faster and a bit cleaner (for my taste).
However, with status quo I will naturally refrain.
One thing that I am quite confident to say is that the final result of issuing a warning is the same as SyntaxError - no one will ever use it and it will become a dark corner no one ever cares to look at again.
So I don’t have a (hard) set mind on this, but after spending a bit of time with it I would be a bit sad to see it go.
What I can say is that I largely support that it either should be a valid Python construct which can be used without any extra obstacles from Python itself or removed.
And to me this would hold regardless of whether there were issues with the warning or not.
I don’t think current half-solution is a good option for this specific instance.
def get_suppress_all1(mapping, key, default=None):
try:
default = mapping[key]
finally:
return default
def get_suppress_all2(mapping, key, default=None):
try:
return mapping[key]
except BaseException:
return default
)