On 05/25/2015 03:22 PM, Eric Snow wrote:

On Mon, May 25, 2015 at 2:40 PM, Terry Reedy <tjreedy@udel.edu> wrote:

...

On 5/25/2015 3:40 PM, Eric Snow wrote:

...

Since Larry already gave an exception, Conditional on 'general approval of the community'. Unless I misunderstood him, Larry gave me an unconditional exception for OrderedDict itself (as long as it is in before beta 2.)

For the record I've granted three exceptions to the beta 1 feature freeze (so far):

• Raymond asked for one (a couple weeks ago!) for adding slice support to collections.deque. He knew he wouldn't have time to finish it before beta 1.
• Serhiy asked for one very-last-minute for a C reimplementation of lru_cache. He checked it in about a half-hour before feature freeze and it made all the buildbots fail. (The ones that weren't already failing, that is.)
• Eric asked for one for this C reimplementation of OrderedDict; the coding was done, the debugging wasn't.

And yes, as Eric said, I made separate pronouncements. I said COrderedDict could go in as long as it was in before beta 2; "the other work" of __definition_order__ and switching type_prepare and __build_class__ to using ordered dicts I made conditional on "general approval of the community." The latter has already been tabled for now.

So, in all three cases it's work that's been under development for a while. These people did this work out of the kindness of their hearts, to make Python better. As a community we want to encourage that and make sure these developers know we appreciate their efforts. These people would be happier if the work shipped in 3.5 as opposed to 3.6 so it got into user's hands sooner.

Also, in Serhiy and Eric's cases, these are reimplementations of existing Python libraries in C. On the one hand, that means we should have good regression test coverage in the library--which it seems like we do, as both of them are debugging problems uncovered by the regression tests. This gives us a little more confidence that the work is good. On the other hand, it does mean there's a higher chance of destabilization, as there's already an installed base using these libraries. (As opposed to something new like math.isclose which has no installed base.) So yes this could introduce bugs that will impact existing users.

Bottom line: while an important part job of my job is saying "no", I also feel like an important part of my job is saying "yes". On balance, what will be best for Python? In these cases, I think "yes" is better.
My feeling is, let's check it in (before beta 2), and if it causes problems during the betas / rcs we can back them out.

//arry/