On 9 Jun 2016, at 14:48, Doug Hellmann <doug@doughellmann.com> wrote:
I agree those are the two options. I want the application developer to make the choice, not us.
Right, but right now those two options aren’t available: only one of them is. And one way or another we’re taking an action here: either we’re leaving os.urandom() as it stands now, or reverting it back to the way it was in 3.4.0. This means that you *do* want python-dev to make a choice: specifically, you want python-dev to make the choice that was made in 3.4.0, rather than the one that was made in 3.5.0. That’s fine, but we shouldn’t be pretending that either side is arguing for inaction or the status quo for Python 3.5 a choice was made with insufficient knowledge of the outcomes, and now we’re arguing about whether we can revert that choice. The difference is, now we *do* know about both outcomes, which means we are consciously choosing between them.
All of which fails to be backwards compatible (new exceptions and hanging behavior), which means you’re breaking apps.
Backwards compatible with what? Python 3.5.0 and 3.5.1 both have this behaviour, so I assume you mean “backward compatible with 3.4”. However, part of the point of a major release is that it doesn’t have to be backward compatible in this manner: Python breaks backward compatibility all the time in major releases. I should point out that as far as I'm aware there are exactly two applications that suffer from this problem. One of them is Debian’s autopkgtest, which has resolved this problem by invoking Python with PYTHONHASHSEED=0. The other is systemd-cron, and frankly it does not seem at all unreasonable to suggest that perhaps systemd-cron should *maybe* hold off until the system’s CSPRNG gets seeded before it starts executing. Cory