On 01/25/2014 05:35 AM, Antoine Pitrou wrote:

Stop the Derby. We needn't convert everything for 3.4 (I didn't even know that was your goal).

Converting everything was my goal at one point. At this point it is nowhere near viable, not the least because there simply isn't enough time. As discussed yesterday on python-dev (subject: "Argument Clinic: what to do with builtins with non-standard signatures?"), and today (subject: "New policies for the Derby -- please read!"), there are large numbers of functions in Python 3.4 that have signatures that can't be expressed by inspect.Signature without semantic changes. Since we can't make those changes for 3.4, we can't convert them to Argument Clinic yet.

//arry/

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.

Regards

Antoine.

On 26 January 2014 02:14, Antoine Pitrou solipsis@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@gmail.com | Brisbane, Australia

On 26 January 2014 22:57, Serhiy Storchaka storchaka@gmail.com wrote:

25.01.14 18:14, Antoine Pitrou написав(ла):

...

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.

There is at least one benefit from Derby: it have exhibited many errors in already clinicalized code and in pydoc and inspect modules (and in Argument Clinic itself).

Right, I think the Derby provided valuable experience, but I also now think Antoine's right that we should postponing any further conversions until 3.5, and focus on cleaning up both the existing conversions, as well as the technical details of working with Argument Clinic.

Specifically, I think we want to have the following in place for 3.4:

1. Larry's patch to make the Argument Clinic signature markers more robust (http://bugs.python.org/issue20326)
2. Generating separate clinic files by default
3. Integrating clinic into "make patchcheck", similar to the reindent.py integration (http://bugs.python.org/issue20264)
4. Adding a commit hook that ensures clinic files have been regenerated prior to commit/push

Regards, Nick.

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

On 25/01/14 19:33, Ethan Furman wrote:

On 01/25/2014 07:40 AM, Nick Coghlan wrote:

...

Basically, I suggest implementing the current bug fixes & minor features AC patch you're working on, and then calling it done for 3.4, with only outright bugs in existing conversions to be fixed before 3.5. [...]

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. [...]

+1 to what he said.

+1. I agree too.

-- Jesús Cea Avión _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ Twitter: @jcea _/_/ _/_/ _/_/_/_/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz

On Sun, Jan 26, 2014 at 9:53 AM, Matthias Klose doko@ubuntu.com wrote:

Am 25.01.2014 14:09, schrieb Larry Hastings:

...

I'd like to extend the Derby by two more weeks and add a fourth beta.

In the past I did like the way how accurate the releases were planned and didn't slip at all, or only slip for a few days.

This may sound a bit selfish, but a few Ubuntu developers do run their own Derby to use 3.4 as the default Python3 version for the next Ubuntu release in April, so a timely release would be appreciated ;)

This actually sounds like a real and interesting reason to have stable Python 3.4 out in march. Ubuntu 14.04 is a LTS, which makes it an important version for corporate distributions.

In addition, other major projects align themselves with released versions of Python. For example Django - I would love to see trunk Django formally support Python 3.4 ASAP.

Eli

On Sun, Jan 26, 2014 at 2:16 PM, Barry Warsaw barry@python.org wrote:

On Jan 26, 2014, at 01:59 PM, Eli Bendersky wrote:

...

This actually sounds like a real and interesting reason to have stable Python 3.4 out in march. Ubuntu 14.04 is a LTS, which makes it an important version for corporate distributions.

Ubuntu 14.04 feature freeze is Feb 20, with beta 1 coming on Feb 27, so I think we have to make a hard decision about whether Python 3.4 will be the default before then (actually, Matthias and I will discuss it this week).

If we go with 3.4 as default, then 14.04 final beta is March 27th. Python 3.4's final release is currently schedule for March 16, but that doesn't include the proposed additional beta. Pushing everything back a week means the schedule is quite tight, so we may have to plan on doing an SRU (stable release upgrade) to the final Python 3.4. That's not ideal though because it means a lot of users may not get it (if they don't upgrade), and most probably won't see it until 14.04.1 is released some time later.

The closer Python 3.4 can stick to the March 16th release, the better.

Yes. That's the whole point of time-based releases. Please stick to the plan. We've already slipped once. Perfection is not required.

-- --Guido van Rossum (python.org/~guido)