[python-committers] Status of the Derby, and request for another slip

[Nick Coghlan]

On 26 January 2014 02:14, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> On dim., 2014-01-26 at 01:40 +1000, Nick Coghlan wrote:
>> I think an extra beta is still a good idea, though - I'd like to get
>> at least the builtins that are already supported converted, since that
>> clearly demonstrates the benefits the tool is designed to bring in
>> reducing the discrepancies between extension code and pure Python
>> code. That patch is done, it just needs a couple of tests cleaned up
>> and a review before it can be merged.
>
> I don't think this is a killer feature that would deserve an extension
> of the release cycle. The feature freeze period is meant for bug fixing,
> not to shoehorn the latest bangs and whistles. Normally the whole Derby
> thing should already have waited for 3.5; in hindsight it would probably
> have been better to do just that.

This is a fair point - I think it would also be reasonable (and quite
possibly preferable) to say "no more clinic conversions for 3.4",
including my almost complete patch for the builtins and any other
almost complete patches. The existing conversions would stay, but our
focus for the remainder of the release cycle could then return to bug
fixes for existing changes (including any genuine bugs in AC for the
already converted extension modules.

I was OK with trying the conversion within the beta period, but I
think the experience of the past couple of weeks has shown that it was
higher impact than we first thought, and that there were more gaps in
the current capabilities of both argument clinic and the inspect
module than we first thought.

By postponing further conversions, we can refocus on the 3.4 release
in the near term, and then update PEP 457 for 3.5 based on our
experience in attempting these conversions for 3.4.

It wouldn't be the first time where a change we've made in one release
has mostly been about setting up a benefit for end users that wasn't
fully realised until the next release (__qualname__ in 3.3 leading to
unbound method pickling support in 3.4 is the main recent example that
comes to mind, but PEP 451 certainly has follow on work that will
continue into 3.5, and the underlying goal of adding
functools.singledispatch was actually to convert the pprint module to
use it, which now won't be happening until 3.5 at the earliest).

While part of my brain is still saying "but we're so close...", I
think I'm coming around to the view that Antoine is right and we
should just stop the Derby and focus on getting the 3.4 release
candidate ready for February 9. It's disappointing, definitely, but
it's also the most responsible course of action available.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia