Home Original page

[Python-Dev] Our responsibilities (was Re: BDFL ruling request: should we block forever waiting for high-quality random bits?)

Random832 random832 at fastmail.com
Thu Jun 16 12:57:09 EDT 2016 
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.
More information about the Python-Dev mailing list