RELEASED Python 2.3 (final)

[Barry A. Warsaw]

On behalf of the Python development team and the Python community, I'm
happy to announce the release of Python 2.3 (final).

Nineteen months in the making, Python 2.3 represents a commitment to
stability and improved performance, with a minimum of new language
features. Countless bugs and memory leaks have been fixed, many new
and updated modules have been added, and the new type/class system
introduced in Python 2.2 has been significantly improved. Python 2.3
can be up to 30% faster than Python 2.2.

For more information on Python 2.3, including download links for
various platforms, release notes, and known issues, please see:

http://www.python.org/2.3

Highlights of this new release include:

- A brand new version of IDLE, the Python IDE, from the IDLEfork
project at SourceForge.

- Many new and improved library modules including: sets, heapq,
datetime, textwrap, optparse, logging, bsddb, bz2, tarfile,
ossaudiodev, itertools, platform, csv, timeit, shelve,
DocXMLRPCServer, imaplib, imp, trace, and a new random number
generator based on the highly acclaimed Mersenne Twister algorithm
(with a period of 2**19937-1). Some obsolete modules have been
deprecated.

- New and improved built-ins including:
o enumerate(): an iterator yielding (index, item) pairs
o sum(): a new function to sum a sequence of numbers
o basestring: an abstract base string type for str and unicode
o bool: a proper type with instances True and False
o compile(), eval(), exec: fully support Unicode, and allow input
not ending in a newline
o range(): support for long arguments (magnitude > sys.maxint)
o dict(): new constructor signatures
o filter(): returns Unicode when the input is Unicode
o int() can now return long
o isinstance(), super(): Now support instances whose type() is not
equal to their __class__. super() no longer ignores data
descriptors, except for __class__.
o raw_input(): can now return Unicode objects
o slice(), buffer(): are now types rather than functions

- Many new doctest extensions, allowing them to be run by unittest.

- 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. (PEP 227)

- Karatsuba long multiplication (running time O(N**1.58) instead of
O(N**2)).

- pickle, cPickle, and copy support a new pickling protocol for more
efficient pickling of (especially) new-style class instances.

- The socket module now supports optional timeouts on all operations.

- ssl support has been incorporated into the Windows installer.

- Many improvements to Tkinter.

Python 2.3 contains many other improvements, including the adoption of
many Python Enhancement Proposals (PEPs). For details see:

http://www.python.org/2.3/highlights.html

Enjoy.

happy-50th-birthday-geddy-ly y'rs,
-Barry

Barry Warsaw
(e-mail address removed)
Python 2.3 Release Manager
(and the PythonLabs team: Tim, Fred, Jeremy, and Guido)

 

[Irmen de Jong]

On behalf of the Python development team and the Python community, I'm
happy to announce the release of Python 2.3 (final).

kudo

1 : AWARD, HONOR <a score of honorary degrees and... other kudos -- Time>
2 : COMPLIMENT, PRAISE <to all three should go some kind of special kudo for
refusing to succumb -- Al Hine>

(M-W)

--Irmen de Jong

 

[John Machin]

kudo

1 : AWARD, HONOR <a score of honorary degrees and... other kudos -- Time>
2 : COMPLIMENT, PRAISE <to all three should go some kind of special kudo for
refusing to succumb -- Al Hine>

(M-W)

--Irmen de Jong

Ahem ... pardon the pedantry, but "kudos" is a mass noun, not the
plural of a count noun. Even were this not so, the development team
(which is singular not only in the counting sense but also in the
sense of being remarkable) deserves more than a single kudo per
member.

So ... could we please change that to "much kudos"?

 

[Ben Finney]

I believe it is customary to use the construction 'great kudos,'
which, in any case, you all deserve.

Or 'totally mega kudos, d00dZ' depending which decade you're living in.

 

[Asun Friere]

Nope. Kudos is a mass noun, but it's a discrete mass noun. So you need
to say "many kudos".

I believe it is customary to use the construction 'great kudos,'
which, in any case, you all deserve.

 

[Carl Banks]

I believe it is customary to use the construction 'great kudos,'
which, in any case, you all deserve.

Am I the only person to say "kudoi to everyone"?

 

[Irmen de Jong]

Or 'totally mega kudos, d00dZ' depending which decade you're living in.

rather, "Thanx 2 all developers 4 ur 1337 c0D1ng Skilzz!!!"

 

[Alan Kennedy]

[Carl Banks]

Am I the only person to say "kudoi to everyone"?

I've never heard anyone say "kudoi". But I suppose it's all about
whether you consider "kudos" to be singular or plural. If it's
singular, then "kudoi" is the only correct (Greek) plural of the
(Greek) singular "kudos".

So all of those Americans who seem intent on turning "kudos" into the
plural of "kudo" (which does not exist, yet) should heed your advice


http://dictionary.reference.com/search?q=kudos

But, of course, the main point of the whole thread is to confer kudos,
i.e. "acclaim or praise for exceptional achievement", on the Python
Development Team.

Thanks People!

regards,

 

[Bengt Richter]

I've been testing reportlab with 2.3 and although it's a lot faster I
get some ominous warnings and complaints from the future.

1) SyntaxWarning: assignment to None
eg for None, name in colorNamePairs:
what is the preferred way to do this nowadays? It's fairly
trivial to go through and change these to for notUsed, x in ....
but is there a nicer way.

I don't know of one, but sometimes I've wanted a way to filter sequence unpacking, e.g,
a,*,c = 1,2,3 # <=> a=1; c=3
and maybe letting ** in the tail position mean dump the rest.

2) FutureWarning: hex/oct constants > sys.maxint will return positive
values in Python 2.4 and up
eg self.assertEquals(ttf.read_ulong(), 0x81020304) # big-endian
Is there no way to preserve the clarity of the above in future?
We have quite a lot of code that deals with low level binary
formatted stuff. Changing will move it further away from the
original C definitions.

How about just defining a C integer class that works as desired?
You could do it in C ;-)

The same applies to

FutureWarning: x<<y losing bits or changing sign will return a long
in Python 2.4 and up
eg sum = (hi << 16) | (lo & 0xFFFF)

Is Python moving away from the machinery? Are there efficient
recipes for doing these 32 bit operations? Certainly cut and
paste to and from java/c/c++ will be a lot harder.

IWT a C extension could be quite efficient. The question would be how
to minimize the editing for cut/pasted stuff. Mostly I guess it would
be wrapping C literals so x = 0x80000000 becomes x = Cint('0x80000000') or such.

Apart from these minor troubles seems pretty solid.

Sounds good.

Regards,
Bengt Richter

 

[Terry Reedy]

living in.

rather, "Thanx 2 all developers 4 ur 1337 c0D1ng Skilzz!!!"

Not being (001 with 1337speak, I googled '1337'
and found this site (#12) that deigned to explain:

http://www.1337-online.com/whatis1337.php

 

[John Baxter]

Nope. Kudos is a mass noun, but it's a discrete mass noun. So you need
to say "many kudos". This bit of pedantry is brought to you by "much
kudo about nothing".

Sometimes, the indiscrete mass nouns are more fun. ;-)

(Perhaps not for major college football coaches, for whom anything
indiscrete can be harmful.)

All this aside, heaps of praise and copious congratulations to all
involved in the release (you know who you are).

And thank you!

--John