Release manager position and steering council seat

“Potentially block forever” was introduced in 3.5, but backing off from that became a hot issue when 3.5.2 was about to be released. Larry knew what he wanted to do, but “literally everyone with a stated opinion else disagrees with me”. That’s why he bumped it up to Guido: there was no consensus to be had.

1 Like

Yeah. The original blocking behavior shipped in 3.5.0, but I didn’t learn about the issue until literally less than a week before 3.5.2rc1.

After that, Victor wrote PEP 524, it was approved, and 3.6 reinstated the blocking behavior for os.urandom().

Ah yes, thanks for filling the memory hole. I recall agreeing with @larry :slight_smile:

The way I remember it, there were three other people on my side: Barry, Tim, and Guido. And since the BDFL agreed with me, that’s what happened. (If there were other people who agreed with me, my apologies for forgetting you, for what that’s worth.)

Given what happened afterwards, I’m not sure this bodes well…

Could you elaborate, please? I followed the issue at the time it was hot, but tuned it out after 3.5.2 was released. What happened afterwards that didn’t work out well? Best I can tell, two PEPs were written, and you picked a winner for 3.6 (restoring potentially blocking behavior , but also adding a different function for apps that couldn’t tolerate that - and pretty much nobody wanted that extra complication slammed in right before 3.5.2 was released).

Some problems are just inherently messy :frowning_face:.

Yes, some things are just messy, but I dislike waffling. Looking back I think we could have lived with the behavior of 3.5.0 and 3.5.1, which would then remain the default in 3.6.0. It seems the old guard (you, me, Barry, Larry) freaked out about the potential for blocking, which was apparently a real thing for some Java app, but IIRC nobody had actually seen it with Python. Endless hours were wasted debating it (the length of the thread is just scary).

The real scary part is that two of those four are now on the SC. Hopefully with the years and the added wisdom of the other SC members we’ll make more stable decisions.

2 Likes

Someone named a mailing list in their address book “os.urandom rehab clinic” because of that! I have no idea who did it, but the name was stuck in my auto-complete for months.

2 Likes

We’ll see :smile: But I really don’t expect this particular one would have gone any better. Because:

That wasn’t it for me at all - couldn’t care less whether it blocked or not. What I did care about is that people expect os to supply thin wrappers around OS functions of the same name, and platform urandom() never blocked, and still doesn’t.

It’s a pretty fundamental design vision there whether the deliberately “low level” os should expose platform functionality or embrace DWSETISHD (Do What Someone Else Thinks I Should Have Done).

From that view, changing Python’s os.urandom() to block in 3.5, despite that the platform urandom() did not change, was the original sin. Linux invented a different function to get blocking behavior when that was wanted, and it was far more in the spirit of os to supply that too (or defer to the secrets module, which intended to give higher-level interfaces and stronger guarantees).

See? We can start the argument all over again, and Larry & Barry will agree with me again here too :slightly_smiling_face:.

That said, I agree too it doesn’t really matter at all. The universe of people writing ultra-early Linux startup scripts in Python is so small it still contains no known member.

3 Likes

Don’t be so sure; it’s the last blocking <ahem> bug before I can release my clone army!

1 Like

Oh no, please, don’t do that :frowning: A decision has been taken, good or bad, I prefer to not reopen this cold case.

1 Like

Nobody has suggested that we do. In context, we were discussing what caused the (in Guido’s words) “waffling” in this case, and how that might have played out under the new governance model.

The specifics of urandom() behavior are (according to me) irrelevant to that. What may be relevant is that this wasn’t nearly so much a technical debate (despite the endless elaboration of technical details in the original thread) as conflict among design philosophies. Those conflicts exist regardless of governance structure, and regardless of which side “wins” in any particular case.

My best guess is that waffling is less likely now, but not for a particularly “good” reason. It’s just that it may be harder for a council to change its collective mind later than for an individual.

FWIW there was a lot I didn’t like about the 3.5.0 os.urandom change. (I believe I wrote a long clp post about my reasons at the time.) I didn’t like changing the behavior of a longstanding library function–I was a bit scandalized when Ted Ts’o unhelpfully said, basically, “backwards compatibility is important for us, but not for you guys, so I think you should change it”. I also didn’t like rewriting an os function as a thick layer over the lower-level function, or changing the semantics from what’s provided by the os. And I didn’t think the sky was falling, that a function that had been in Python for 14 years continued to have the flaws it had had since the beginning.

I thought the best thing was to write a new function and get people to migrate over. But I stayed out of it, and folks got a PEP accepted and changed os.urandom for 3.6, oh well. That ship has definitely sailed.

3 Likes