[Python-Dev] Preserving the definition order of class namespaces.

[Larry Hastings]

On 05/25/2015 03:22 PM, Eric Snow wrote:
> On Mon, May 25, 2015 at 2:40 PM, Terry Reedy <tjreedy at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150525/b101f8fd/attachment.html>