Python 2.3c2 is the second and last release candidate for Python 2.3. There have been a bunch of bug fixes and memory leak plugs since the first release candidate, but no new features. As described in PEP 283, Python 2.3 final will be released before the end of July 2003. We are planning for Tuesday 29-Jul-2003 if everything looks good. We highly encourage everyone to rigorously test this release candidate. Only critical bug fixes will be allowed from here to the final release, but we want this release to be as stable as possible. Highlights since rc1 include: - It is now possible to import from zipfiles containing additional data bytes before the zip compatible archive. Zipfiles containing a comment at the end are still unsupported. - Fixed leaks in pyexpat and locale, and a long standing bug in the parser module. - The MacOSX build is now built with -mno-fused-madd to fix test_coercion on Panther (OSX 10.3). For more highlights, see http://www.python.org/2.3/highlights.html Other new stuff since Python 2.2: - Many new and improved library modules, e.g. sets, heapq, datetime, textwrap, optparse, logging, bsddb, bz2, tarfile, ossaudiodev, and a new random number generator based on the highly acclaimed Mersenne Twister algorithm (with a period of 2**19937-1!). - New builtin enumerate(): an iterator yielding (index, item) pairs. - Extended slices, e.g. "hello"[::-1] returns "olleh". - Universal newlines mode for reading files (converts \r, \n and \r\n all into \n). - Source code encoding declarations. (PEP 263) - Import from zip files. (PEP 273 and PEP 302) - FutureWarning issued for "unsigned" operations on ints. (PEP 237) - Faster list.sort() is now stable. - Unicode filenames on Windows. - Karatsuba long multiplication (running time O(N**1.58) instead of O(N**2)). To report problems, use the SourceForge bug tracker: http://sourceforge.net/tracker/?group_id=5470&atid=105470 brought-to-you-by-the-letter-'D'-for-drifty-ly y'rs, -Barry
On Thu, 2003-07-24 at 23:01, Barry Warsaw wrote:
As described in PEP 283, Python 2.3 final will be released before the end of July 2003. We are planning for Tuesday 29-Jul-2003 if everything looks good.
Please note! I've updated PEP 283 to reflect my hope that we can put out 2.3 final next Tuesday the 29th. We don't want to cut it so close that we get screwed if SF takes a holiday on the 31st. I think we're very very close (discussions about the timeRE cache later), so I hope we can hit this date. If anybody feels otherwise, now's the time to bark loudly! -Barry
On Thu, Jul 24, 2003, Barry Warsaw wrote:
On Thu, 2003-07-24 at 23:01, Barry Warsaw wrote:
As described in PEP 283, Python 2.3 final will be released before the end of July 2003. We are planning for Tuesday 29-Jul-2003 if everything looks good.
Please note! I've updated PEP 283 to reflect my hope that we can put out 2.3 final next Tuesday the 29th. We don't want to cut it so close that we get screwed if SF takes a holiday on the 31st. I think we're very very close (discussions about the timeRE cache later), so I hope we can hit this date. If anybody feels otherwise, now's the time to bark loudly!
This is fine with me, but I'd like the official docs to still state that the release takes place on 7/31. This will facilitate coordiantion of the press releases, I think. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ This is Python. We don't care much about theory, except where it intersects with useful practice. --Aahz
On Thu, 2003-07-24 at 23:14, Aahz wrote:
This is fine with me, but I'd like the official docs to still state that the release takes place on 7/31. This will facilitate coordiantion of the press releases, I think.
Here's another option: we do absolutely everything we need to do that involves SF on the 29th. This means freezing, tagging, and branching the tree, building the tarballs and exes, etc. But we don't send the announcement or twiddle the python.org home page until the 31st. That way, it's official on the 31st, but everyone who needs it (i.e. Apple) can have it by the 29th. Thoughts? -Barry
On Thu, Jul 24, 2003, Barry Warsaw wrote:
On Thu, 2003-07-24 at 23:14, Aahz wrote:
This is fine with me, but I'd like the official docs to still state that the release takes place on 7/31. This will facilitate coordiantion of the press releases, I think.
Here's another option: we do absolutely everything we need to do that involves SF on the 29th. This means freezing, tagging, and branching the tree, building the tarballs and exes, etc.
But we don't send the announcement or twiddle the python.org home page until the 31st. That way, it's official on the 31st, but everyone who needs it (i.e. Apple) can have it by the 29th.
Thoughts?
Works for me! (And was one variation I was too terse to list myself.) -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ This is Python. We don't care much about theory, except where it intersects with useful practice. --Aahz
[Barry]
Here's another option: we do absolutely everything we need to do that involves SF on the 29th. This means freezing, tagging, and branching the tree, building the tarballs and exes, etc.
But we don't send the announcement or twiddle the python.org home page until the 31st.
Why would we possibly want to do that?
[Barry]
Please note! I've updated PEP 283 to reflect my hope that we can put out 2.3 final next Tuesday the 29th.
[Aahz]
This is fine with me, but I'd like the official docs to still state that the release takes place on 7/31. This will facilitate coordiantion of the press releases, I think.
What's the logic here? Is the general algorithm that if we do a release on date D, the official docs should say it was released on date D+2? Or that the official docs should say that a release occurred on the last day of the month at or following the actual release date? The next Thursday after the actual release? It can't be that you want to see the first prime date at or after the actual release, unless there's been an arithmetic error <wink>.
On Thu, Jul 24, 2003, Tim Peters wrote:
[Aahz]
[Barry]
Please note! I've updated PEP 283 to reflect my hope that we can put out 2.3 final next Tuesday the 29th.
This is fine with me, but I'd like the official docs to still state that the release takes place on 7/31. This will facilitate coordiantion of the press releases, I think.
What's the logic here? Is the general algorithm that if we do a release on date D, the official docs should say it was released on date D+2? Or that the official docs should say that a release occurred on the last day of the month at or following the actual release date? The next Thursday after the actual release? It can't be that you want to see the first prime date at or after the actual release, unless there's been an arithmetic error <wink>.
No, it's that there are press releases that are dependent on this release, particularly the one involving Apple. I think that hard-coding the press releases *now* offers advantages for coordinating the actual release process, so that we don't need to worry about updating them. What happens if the actual release slips just one day? In the past, our pattern has been that the press release follows the product release, but that's not happening this time. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ This is Python. We don't care much about theory, except where it intersects with useful practice. --Aahz
On Thu, 2003-07-24 at 23:31, Aahz wrote:
No, it's that there are press releases that are dependent on this release, particularly the one involving Apple. I think that hard-coding the press releases *now* offers advantages for coordinating the actual release process, so that we don't need to worry about updating them. What happens if the actual release slips just one day?
In the past, our pattern has been that the press release follows the product release, but that's not happening this time.
OTOH, I'm going to let our press release partners know that 29-Jul-2003 is the release date -- if no one objects before I wake up in the morning. I think the press releases can be updated here easily. -Barry
I get one test failure on Mac OS 10.2.6: test test_pwd failed -- Traceback (most recent call last): File "/Temporary Items/Python-2.3c2/Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) KeyError: 'getpwuid(): uid not found' The passwd entry on which it fails looks perfectly normal, AFAICS. We've got about 3500 entries in our passwd file, if that's of interest. Bill
Bill Janssen wrote:
I get one test failure on Mac OS 10.2.6:
test test_pwd failed -- Traceback (most recent call last): File "/Temporary Items/Python-2.3c2/Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) KeyError: 'getpwuid(): uid not found'
The passwd entry on which it fails looks perfectly normal, AFAICS. We've got about 3500 entries in our passwd file, if that's of interest.
Could you make a bug report on Sourceforge and assign it to me? Bye, Walter Dörwald
OK, done. It's 779218. Bill
I get one test failure on Mac OS 10.2.6:
test test_pwd failed -- Traceback (most recent call last): File "/Temporary Items/Python-2.3c2/Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) KeyError: 'getpwuid(): uid not found'
The passwd entry on which it fails looks perfectly normal, AFAICS. We've got about 3500 entries in our passwd file, if that's of interest.
Not in the sense that you mean, I think. There is one entry in it which contains a '+' among other text in the name of the entry. Bill
On Mon, 2003-07-28 at 19:18, Bill Janssen wrote:
OK, done. It's 779218.
Bill
Thanks Bill. Is there a `+' in your /etc/passwd file?
See 775964
-Barry
On Tue, 2003-07-29 at 16:37, Bill Janssen wrote:
Not in the sense that you mean, I think. There is one entry in it which contains a '+' among other text in the name of the entry.
That probably doesn't matter. I think it's a plus (or a minus?) as the first character on the line. But we'll look into this more after 2.3 final goes out. Thanks, -Barry
On Thu, Jul 24, 2003 at 11:01:05PM -0400, Barry Warsaw wrote:
We highly encourage everyone to rigorously test this release candidate.
Looks good under Cygwin. Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
participants (6)
-
Aahz -
Barry Warsaw -
Bill Janssen -
Jason Tishler -
Tim Peters -
Walter Dörwald