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:
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
ba...@python.org
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
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"?
Aahz
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".
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
This is Python. We don't care much about theory, except where it intersects
with useful practice. --Aahz
Asun Friere
> In article <c76ff6fc.03073...@posting.google.com>,
> John Machin <sjma...@lexicon.net> wrote:
> >
> >So ... could we please change that to "much kudos"?
>
> 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
Am I the only person to say "kudoi to everyone"?
--
CARL BANKS
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.
--
\ "He may look like an idiot and talk like an idiot but don't let |
`\ that fool you. He really is an idiot." -- Groucho Marx |
_o__) |
Ben Finney <http://bignose.squidly.org/>
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
> 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,
--
alan kennedy
-----------------------------------------------------
check http headers here: http://xhaus.com/headers
email alan: http://xhaus.com/mailto/alan
Robin Becker
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.
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.
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.
Apart from these minor troubles seems pretty solid.
--
Robin Becker
Ben Finney
> 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.
Seems nice enough. You'll only be able to assign to a mutable object
anyway; None is not mutable, and will soon be a keyword. Define (or
just go ahead and use) your own not_used name.
> 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?
Declare large positive constants as being longs:
>>> foo = 0xFFFFFFFF
<stdin>:1: FutureWarning: hex/oct constants > sys.maxint will return positive values in Python 2.4 and up
>>> foo
-1
>>> foo = 0xFFFFFFFFL
>>> foo
4294967295L
You probably want the numbers to behave as positive anyway.
> 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)
Same answer applies too:
>>> hi = 0xDEAD
>>> lo = 0xBEEF
>>> sum = ( hi << 16 ) | ( lo & 0xFFFF )
__main__:1: FutureWarning: x<<y losing bits or changing sign will return a long in Python 2.4 and up>>> sum
-559038737
>>> hi = 0xDEADL
>>> lo = 0xBEEFL
>>> sum = ( hi << 16 ) | ( lo & 0xFFFF )
>>> sum
3735928559L
If you want to deal consistently (across Python versions) with numbers
larger than sys.maxint, whether decimal, hex or octal, ensure you set
them up as longs to begin with.
> Is Python moving away from the machinery?
I don't see why not; fiddling with low-level bits is pretty
architecture-dependent, as these hacks show. If you want C, you know
where to find it.
> Are there efficient recipes for doing these 32 bit operations?
Hopefully you'll agree the solutions I've presented are just as
"efficient", even if they expose the bit-fiddling hackery somewhat more.
> Certainly cut and paste to and from java/c/c++ will be a lot harder.
I've never known that to be a priority for Python.
--
\ "I went to a restaurant that serves 'breakfast at any time'. So |
`\ I ordered French Toast during the Renaissance." -- Steven |
_o__) Wright |
Ben Finney <http://bignose.squidly.org/>
Bengt Richter
>In article <c76ff6fc.03073...@posting.google.com>,
>John Machin <sjma...@lexicon.net> wrote:
>>
>>So ... could we please change that to "much kudos"?
>
>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".
"""
kudos, Greek for glory, became an English slang word
of limited currency at a time when Greek was more widely learnt,
and is now, it seems, sometimes mistaken for a plural.
"""
H.W.Fowler, in "A Dictionary of Modern English Usage," 2nd ed., 1965
(Elsewhere it does acknowledge that Edmund Wilson wrote of
American usage in 1963, "Kudos seems now to be well established
as the plural of a word meaning "honourable mention
or prize or something of the sort.")
Regards,
Bengt Richter
Aahz
Robin Becker <ro...@jessikat.fsnet.co.uk> wrote:
>
>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.
Some people use "_".
sism...@hebmex.com
> Sent: Jueves, 31 de Julio de 2003 12:17 p.m.
>
> > Seems nice enough. You'll only be able to assign to a
> > mutable object anyway;
>
> binding operating is mutability is not a relevant issue.
>
> > None is not mutable, and will soon be a keyword.
>
>
> Cheers,
> Brian
>
Nope; it has to do with making Python faster: if constants
such as None, True, False are treated as true constants,
then certain optimizations can be enabled with help make
it all a bit quicker.
So, in order to do so, assignment to builtins is being
disallowed; or, only to such singleton instances...
I'm not too sure anymore.
Anyway, there's a thread in comp.lang.dev about all
this.
HTH
-gustavo
Advertencia:La informacion contenida en este mensaje es confidencial y
restringida, por lo tanto esta destinada unicamente para el uso de la
persona arriba indicada, se le notifica que esta prohibida la difusion de
este mensaje. Si ha recibido este mensaje por error, o si hay problemas en
la transmision, favor de comunicarse con el remitente. Gracias.
Brian Quinlan
> anyway;
This statement doesn't make any sense. Assignment to None is a name
binding operating is mutability is not a relevant issue.
> None is not mutable, and will soon be a keyword.
None becoming a keyword is a valid reason.
Cheers,
Brian
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
"Irmen de Jong" <irmen@-NOSPAM-REMOVETHIS-xs4all.nl> wrote in message
Not being (001 with 1337speak, I googled '1337'
and found this site (#12) that deigned to explain:
John Baxter
wrote:
> 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