On 05/25/2015 03:22 PM, Eric Snow wrote:
On Mon, May 25, 2015 at 2:40 PM, Terry Reedy <email@example.com> 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):
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.
- 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.
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