On Thu, Jun 16, 2016, at 07:34, Donald Stufft wrote:
python-dev tends to favor not breaking “working” code over securing existing APIs, even if “working” is silently doing the wrong thing in a security context. This is particularly frustrating when it comes to security because security is by it’s nature the act of taking code that would otherwise execute and making it error, ideally only in bad situations, but this “security’s purpose is to make things break” nature clashes with python-dev’s default of not breaking “working” code in a way that is personally draining to me.
I was almost about to reply with "Maybe what we need is a new zen of python", then I checked. It turns out we already have "Errors should never pass silently" which fits *perfectly* in this situation. So what's needed is a change to the attitude that if an error passes silently, that making it no longer pass silently is a backward compatibility break. This isn't Java, where the exceptions not thrown by an API are part of that API's contract. We're free to throw new exceptions in a new version of Python.