<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-text-html" lang="x-western"> <br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Here's how I propose we move forward.<br>
<br>
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.)<br>
<br>
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.<br>
<br>
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:<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
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.<br>
<br>
<br>
<i>/arry</i><br>
</div>
</body>
</html>