[Python-Dev] Python 3.4: What to do about the Derby patches

Larry Hastings larry at hastings.org
Sun Feb 16 19:31:21 CET 2014

Let's begin with a status update of The Great Argument Clinic Conversion 
Derby.  In retrospect, the Derby was way too ambitious.  Once it started 
I was quickly overwhelmed.  Even doing nothing but Derby work, all day 
every day for two straight weeks, I couldn't keep up with all the bug 
fixes, feature requests, correspondence, and documentation updates it 
demanded.  There was no way I could simultaneously review patches too.

As a result: there is, still, an enormous backlog of Derby patches that 
need reviewing.  Few of the Derby patches got integrated before we 
reached rc1.

The underlying theory of the Derby was that it would be a purely 
mechanical process.  It would be a simple matter of converting the 
existing parsing code into its Argument Clinic equivalent, resulting 
solely in code churn.  And, indeed, a significant portion of the Derby 
patches are exactly that.  But the conversion process peered into a lot 
of dusty corners, and raised a lot of questions, and as a result it was 
a much more complicated and time-consuming process than I anticipated.

So here we are in the "release candidate" period for 3.4, and we still 
have all these unmerged Derby patches.  And it's simply too late in the 
release cycle to merge them for 3.4.0.

Here's how I propose we move forward.

1) We merge the Derby patch for the builtins module into 3.4, simply 
because it will "demo well".  If someone wants to play with signatures 
on builtins, I think it's likely they'll try something like "len".  
Obviously this wouldn't be permitted to change the semantics of argument 
parsing in any way--this would be a "code churn" patch only.  (In case 
you're wondering, Nick did the conversion of the builtins module, and 
naturally I will be reviewing it.)

2) We change all Clinic conversions in 3.4 so they write the generated 
code to a separate file--in Clinic parlance, change them so they 'use 
the "file" destination'.  Going forward this will be the preferred way 
to check in Argument Clinic changes into Python.

These first two are the only changes resulting from the Derby that I 
will accept between now and 3.4.0 final, and I expect to have them in 
for 3.4.0rc2.  Continuing from there:

3) We hold off on merging the rest of the Derby patches until after 
3.4.0 final ships, then we merge them into the 3.4 maintenance branch so 
they go into 3.4.1.  We use the time between now and then to get the 
patches totally, totally perfect.  Again, these patches will not be 
permitted to change the parsing semantics of the functions so 
converted.  I expect to do these checkins in a private branch, and land 
the bulk of it immediately upon the opening of the 3.4 maintenance branch.

4) We accelerate the schedule for 3.4.1 slightly, so we can get these 
new signatures into the hands of users sooner. Specifically, I propose 
we ship 3.4.1 two months after 3.4.0.  I figure we would release 3.4.1 
rc1 on Sunday May 4th, and 3.4.1 final on Sunday May 18th.

5) Any proposed changes in Derby patches that change the semantics of a 
builtin may only be checked into default for 3.5, after 3.4.0 ships.

I'm very sorry that many people contributed to the Derby expecting their 
patches to go in to 3.4.  This is my fault, for severely miscalculating 
how the Derby would play out.  And I feel awful about it.  But I'm 
convinced the best thing for Python is to hold off on merging until 
after 3.4.0 ships.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140216/8a0922be/attachment.html>

More information about the Python-Dev mailing list