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.
//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
