> As for the rest, I'm not as sure and it would be helpful to get > thoughts > from others on this one. My sense is that blocking the clause from > appearing in the middle is treating the symptom and not the disease. +1 It would be better to prohibit bare except entirely (well, presumably at some point in the future with appropriate warnings at the moment) than change its semantics. I agree that its intuitive meaning is "if anything is thrown", not, "if a non-programmer-error exception is thrown," but I'm not sure if that's even important. The point is that it has existing well defined semantics; changing them just seems unnecessary to the aims of the rewrite and confusing to existing Python programmers. I've written plenty of code with bare excepts and they all intended to catch *any* exception, usually in a user interface where I wanted to return to the main loop on programmer error not abort the entire program. I don't relish the thought of going back and changing existing code, and I imagine there are few who do. My 2 cents, Niko
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4