On 05/25/2015 03:22 PM, Eric Snow wrote:
On Mon, May 25, 2015 at 2:40 PM, Terry Reedy <tjre...@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/
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
