Have you ever: Been disappointed, surprised or hurt by a library etc. that had a bug that could have been fixed with inheritance and few lines of code, but due to private / final methods and classes were forced to wait for an official patch that might never come? I have. Wanted to use a library for a slightly different use case than was imagined by the authors but were unable to do so because of private / final methods and classes? I have.

This is especially useful for UI library components, as it is generally unknown which events will be required from them for all desired use cases. For example, if a Button component only forwards a click event, then no use case that requires the mouseover or the keypress event can be used with it.

This creates what is essentially an evolution process for the program, causing it to depart from the original engineered design. As a consequence of this and a changing environment, assumptions made by the original designers may be invalidated, introducing bugs.

When changes occur in the program's environment, particularly changes which the designer of the program did not anticipate, the software may no longer operate as originally intended.

Literally, everything in this example can go wrong. Here’s an incomplete list of all possible errors that might occur: Your network might be down, so request won’t happen at all The server might be down The server might be too busy and you will face a timeout The server might require an authentication API endpoint might not exist The user might not exist You might not have enough permissions to view it The server might fail with an internal error while processing your request The server might return an invalid or corrupted response The server might return invalid json, so the parsing will fail And the list goes on and on! There are so maybe potential problems with these three lines of code, that it is easier to say that it only accidentally works. And normally it fails with the exception.

Almost everything in python can fail with different types of exceptions: division, function calls, int, str, generators, iterables in for loops, attribute access, key access, even raise something() itself may fail. I am not even covering IO operations here. And checked exceptions won’t be supported in the nearest future.

I understand your point and yes, at least as of now, the issue is purely related to #4652 (can’t exclude that others will find different uses in the future, however).