On Sun, Feb 15, 2009 at 10:59 AM, Guido van Rossum <guido@python.org> wrote:

On Sat, Feb 14, 2009 at 12:29 PM, Benjamin Peterson <benjamin@python.org> wrote:

...

3.1a1 March 7 (Saturday) 3.1a2 April 11 (Saturday) 3.1b1 May 2 (Saturday) 3.1b2 May 23 (Saturday) 3.1rc1 June 13 (Saturday) 3.1rc2 June 27 (Saturday)

And final release on...?

Oops! Forgot about that one. :) July 4th.

...

I'm interested in your feedback with regards to the amount of time in beta and RC phase. Do you think we need that much time? Otherwise, we could move the final release back sometime in mid June.

It's a bit hard to compare this to other release schedules because it's coming much sooner after 3.0. I would guess this means that not as much has changed, and so the schedule could conceivably more compressed. If you want to take beta seriously as a time of consolidation where no new features should be added and no API changes should take place, you might consider dropping one beta, since in practice it is often hard to keep developers from wanting to change stuff anyways.

Something like this? 3.1a1 March 7 3.1a2 April 4 3.1b1 May 2 3.1rc1 May 30 3.1rc2 June 13 3.1 Final June 27 That sounds reasonable. I will try to enforce a fairly strict stability policy during the beta and RCs.

You might also want to collect a list of serious changes that you want in this release; I know I/O in C is on the list (and without it I wouldn't consider it worth releasing) but there may be others. The developers of such features ought to be on board with delivering their code before the first beta.

I've started a list on the release PEP [1]. [1] http://www.python.org/dev/peps/pep-0375/ -- Regards, Benjamin

On Tue, Feb 17, 2009 at 7:55 AM, Gregor Lingl <gregor.lingl@aon.at> wrote:

...

I've started a list on the release PEP [1].

[1] http://www.python.org/dev/peps/pep-0375/

Is the intention to release 2.7 and 3.1 in parallel?

No.

I suspect, comparing this to

http://www.python.org/dev/peps/pep-0373/

that there is some name mangling in pep-0375?

It seems I left "2.7" in the prose a few times. I've fixed that now. -- Regards, Benjamin

Benjamin,

...

You might also want to collect a list of serious changes that you want in this release; I know I/O in C is on the list (and without it I wouldn't consider it worth releasing) but there may be others. The developers of such features ought to be on board with delivering their code before the first beta.

I've started a list on the release PEP [1].

[1] http://www.python.org/dev/peps/pep-0375/

I think you could add "update json package to reflect the current simplejson version" (see http://bugs.python.org/issue4136). cheers Antoine.

2009/2/27 Raymond Hettinger <python@rcn.com>:

...

...

...

You might also want to collect a list of serious changes that you want in this release; I know I/O in C is on the list (and without it I wouldn't consider it worth releasing) but there may be others. The developers of such features ought to be on board with delivering their code before the first beta.

I've started a list on the release PEP [1].

[1] http://www.python.org/dev/peps/pep-0375/

I think you could add "update json package to reflect the current simplejson version" (see http://bugs.python.org/issue4136).

Also, I'm expecting that ordered dictionaries will be ready:  http://www.python.org/dev/peps/pep-0372/

Thanks. I've added these items to the PEP. -- Regards, Benjamin

2009/2/27 Nick Coghlan <ncoghlan@gmail.com> schrieb:

I should have a PEP (and implementation) ready for alpha 2 to address the current discrepancy between contextlib.nested and actual nested with statements: http://bugs.python.org/issue5251

If you do add a reference to that bug report to the release PEP, mark fixing it as a maybe though - with the associated PEP not even written yet, I obviously still have some work to do to get the semantic change approved by Guido and the rest of python-dev.

Ok. I've added it. -- Regards, Benjamin

Paul Moore wrote:

2009/2/27 Benjamin Peterson <benjamin@python.org>:

...

2009/2/27 Nick Coghlan <ncoghlan@gmail.com> schrieb:

...

I should have a PEP (and implementation) ready for alpha 2 to address the current discrepancy between contextlib.nested and actual nested with statements: http://bugs.python.org/issue5251

If you do add a reference to that bug report to the release PEP, mark fixing it as a maybe though - with the associated PEP not even written yet, I obviously still have some work to do to get the semantic change approved by Guido and the rest of python-dev. Ok. I've added it.

Is it worth getting simplegeneric exposed in 3.1 (http://bugs.python.org/issue5135)? If it's going to be in 2.7, I'd like to see it hit 3.1. The patch is against trunk (for 2.7) at the moment, I'm not sure what the process would be for forward-porting it (do I generate a new patch against the py3k branch, or should it be applied to trunk and merged in?)

As much as I'd like to get a simple generic implementation into functools, the lack of support for ABCs still bothers me (despite my last post about that on the tracker item). I'd be a -0 on it going in as is, but if someone can figure out a clever way of supporting ABCs without completing killing the invocation speed for generics, that would go up to a +1. (The current difficulty of this may actually reflect a more significant limitation on the available metadata for ABCs in PEP 3119: it is easy to ask "is this specific type an example of this ABC?", but difficult to ask "which ABCs is this type as example of?". For actual inheritance, the __mro__ attribute means that both questions are easy to answer, but I'm not aware of any corresponding way of answering the latter question for ABCs) Cheers, Nick. P.S. I just unassigned myself from that tracker item - I'm going to have my hands full working on the proposed change to the with statement. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

On Sun, 2009-03-01 at 23:04 +0100, Cesare Di Mauro wrote:

Running the test suite with Python 2.6.1 32 bit (compiled in DEBUG mode with Visual Studio Express Edition 2008) on Vista x64, I've got an assert error:

test_1686475 (__main__.StatAttributeTests) ... Assertion failed: (__int64)(int)((in / 10000000) - secs_between_epochs) == ((in / 10000000) - secs_between_epochs), file ..\Modules\posixmodule.c, line 790

I have no idea about this failure. Any hint?

[I haven't checked the test yet, let me know if my guess is wrong :)]. It looks to me that its asserting something to do with stat times; note that windows has up to a 2 second granularity for stat times on files - you may be hitting some code that assumes a sane file system :) -Rob

On Mar, 02 2009 at 00:13AM, Amaury Forgeot d'Arc <amauryfa@gmail.com> wrote:

Hello,

On Sun, Mar 1, 2009 at 23:04, Cesare Di Mauro <cesare.dimauro@a-tono.com> wrote:

...

Running the test suite with Python 2.6.1 32 bit (compiled in DEBUG mode with Visual Studio Express Edition 2008) on Vista x64, I've got an assert error:

test_1686475 (__main__.StatAttributeTests) ... Assertion failed: (__int64)(int)((in / 10000000) - secs_between_epochs) == ((in / 10000000) - secs_between_epochs), file ..\Modules\posixmodule.c, line 790

I have no idea about this failure. Any hint?

The failing assertion comes from this code in posixmodule.c:

/* XXX Win32 supports time stamps past 2038; we currently don't */ *time_out = Py_SAFE_DOWNCAST((in / 10000000) - secs_between_epochs, __int64, int);

the test (btw, it's in test_os.py) is trying os.stat(r"c:\pagefile.sys")

Can you please check the three time stamps of this file (creation, update, access)?

You are right. The last modified timestamp had 2099 as year value (the maximum that I can set on Windows), because of some tests with dates which I made at the time. However, they are correct timestamps for Windows files, so I think that at least the API on posixmodule.c should not fail when working with them. I don't know if there's a way to handle them correctly. Also may be that test_os.py need to be changed in some way, because the pagefile can be put in any partition, and there are Windows installations which lack it, because the virtual memory can be disabled too. Cheers Cesare

On Mon, Mar 2, 2009 at 13:25, Nick Coghlan <ncoghlan@gmail.com> wrote:

Cesare Di Mauro wrote:

...

However, they are correct timestamps for Windows files, so I think that at least the API on posixmodule.c should not fail when working with them. I don't know if there's a way to handle them correctly.

Use 64-bit time values (which is highly unlikely to ever be the case for CPython on a 32-bit OS).

64bit time_t is the default since VS2005. See the patch at http://bugs.python.org/issue4379 -- Amaury Forgeot d'Arc

Hi, Benjamin Peterson wrote:

3.1a1 March 7 3.1a2 April 4 3.1b1 May 2 3.1rc1 May 30 3.1rc2 June 13 3.1 Final June 27

Benjamin, I'd like to nominate a couple (minor) RFEs[1] and bug fixes[2] for 3.1. By 'nominate' I mean 'group related issues together, offer tests, docs, patches and/or reviews as needed and ask-pretty-please-for-inclusion' :) Would early post-3.1a1 versus pre-3.1a1 make a difference in likelihood of proposed changes going in? I can try to come up with a detailed list before March 5, but I'd rather present it next week, after taking a look at all remaining open issues. FWIW, further tracker cleanup should happen sometime next week, let me know if you need any tracker janitorvelopment done :) Regards, Daniel [1] Current list: http://bugs.python.org/issue1097797 http://bugs.python.org/issue3244 http://bugs.python.org/issue736428 http://bugs.python.org/issue1175686 http://bugs.python.org/issue4733 [2] Examples: http://bugs.python.org/issue4953 http://bugs.python.org/issue1074333

Benjamin Peterson wrote:

...

You might also want to collect a list of serious changes that you want in this release; I know I/O in C is on the list (and without it I wouldn't consider it worth releasing) but there may be others. The developers of such features ought to be on board with delivering their code before the first beta.

I've started a list on the release PEP [1].

[1] http://www.python.org/dev/peps/pep-0375/

Please add "auto-numbered replacement fields in str.format() strings" <http://bugs.python.org/issue5237> Guido wrote today "Please go ahead and finish this. I'm glad this is going in!" Eric Smith says he should have a final patch ready by the end of PyCon or so.

>>> You might also want to collect a list of serious changes that you >>> want in this release; http://bugs.python.org/issue4847 Not yet fixed. Needs: * Decision about the correct fix (I think it will involve an API change). * Test case and a patch. * Probably small documentation changes as well. I'm wiped out this evening. I'll try to look into it, but I suspect it might require a bit more time than I have in the next day or two. Skip

2009/3/9 Raymond Hettinger <python@rcn.com>:

...

  >>> You might also want to collect a list of serious changes that you   >>> want in this release;

Bob Ippolito has a good sized patch to update the json module and improve its performance.

http://bugs.python.org/issue4136

...and it's already on the PEP. :) -- Regards, Benjamin

I'm making minor updates to the decimal module to match the 1.68 version of the spec.

Looks like most was already done. Just needs some doc fixes. Raymond

Antoine Pitrou wrote:

Raymond Hettinger <python <at> rcn.com> writes:

...

...

...

...

You might also want to collect a list of serious changes that you want in this release; I'm making minor updates to the decimal module to match the 1.68 version of the spec.

What about decimal-in-C, by the way? Is anyone still working on it?

There was a bit of a difference in philosophy between Mark and Raymond as to how best to proceed with speeding it up (Mark's patch [1] focuses solely on speeding up mantissa manipulation, while Raymond suggested a more extensive rewrite in C would be preferable), so progress on the issue stalled. It would probably require at least a comment from Raymond saying to proceed with the custom mantissa type approach to get that patch moving again. Alternatively, if Raymond actually gets the project sponsorship he mentioned a couple of months ago, that would also get things moving again (just in a different direction). Cheers, Nick. [1] http://bugs.python.org/issue2486 -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

Raymond Hettinger wrote:

[Nick Coghlan]

...

...

What about decimal-in-C, by the way? Is anyone still working on it?

I'm seeking funding for the project. If it is forthcoming, I intend to do a pure C version that simply implements the spec and then adds wrappers for the pure python interface. That will save the cost of constantly creating and modifying many pyobjects that currently arise during intermediate calculations. It's possible to focus just of the mantissa calculations but the cost of the actual arithmetic work is swapped by the overhead of managing contexts, checking for special values, and memory allocations. Without addressing those, I think decimal will remain critically performance challenged compared to native floats (decimals will never be that fast, but they can get close enough to make them a viable alternative for many kinds of work).

I actually agree with all that, but do you agree the mantissa work is still worthwhile in the near term (i.e. 3.1) to address the 25% or so slowdown between decimal in 2.x (with the mantissa as an 8-bit str) and decimal in 3.0 (with the mantissa as a unicode str, because using a bytes object to store the digits is actually slower due to the lack of a bytes->long fast path)? Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------