Date: Mon, 22 Jan 2001 22:33:02 -0500
From: Guido van Rossum (firstname.lastname@example.org)
To: email@example.com, firstname.lastname@example.org
Subject: [Python-Dev] Python 2.1 alpha 1 released!
Thanks to the PythonLabs developers and the many hard-working
volunteers, I'm proud to release Python 2.1a1 -- the first alpha
release of Python version 2.1.
The release mechanics are different than for previous releases: we're
only releasing through SourceForge for now. The official source
tarball is already available from the download page:
Additional files will be released soon: a Windows installer,
Linux RPMs, and documentation.
Please give it a good try! The only way Python 2.1 can become a
rock-solid product is if people test the alpha releases. Especially
if you are using Python for demanding applications or on extreme
platforms we are interested in hearing your feedback. Are you
embedding Python or using threads? Please test your application using
Python 2.1a1! Please submit all bug reports through SourceForge:
Here's the NEWS file:
What's New in Python 2.1 alpha 1?
Core language, builtins, and interpreter
- - There is a new Unicode companion to the PyObject_Str() API
called PyObject_Unicode(). It behaves in the same way as the
former, but assures that the returned value is an Unicode object
(applying the usual coercion if necessary).
- - The comparison operators support "rich comparison overloading" (PEP
207). C extension types can provide a rich comparison function in
the new tp_richcompare slot in the type object. The cmp() function
and the C function PyObject_Compare() first try the new rich
comparison operators before trying the old 3-way comparison. There
is also a new C API PyObject_RichCompare() (which also falls back on
the old 3-way comparison, but does not constrain the outcome of the
rich comparison to a Boolean result).
The rich comparison function takes two objects (at least one of
which is guaranteed to have the type that provided the function) and
an integer indicating the opcode, which can be Py_LT, Py_LE, Py_EQ,
Py_NE, Py_GT, Py_GE (for <, <=, ==, !=, >, >=), and returns a Python
object, which may be NotImplemented (in which case the tp_compare
slot function is used as a fallback, if defined).
Classes can overload individual comparison operators by defining one
or more of the methods__lt__, __le__, __eq__, __ne__, __gt__,
__ge__. There are no explicit "reflected argument" versions of
these; instead, __lt__ and __gt__ are each other's reflection,
likewise for__le__ and __ge__; __eq__ and __ne__ are their own
reflection (similar at the C level). No other implications are
made; in particular, Python does not assume that == is the Boolean
inverse of !=, or that < is the Boolean inverse of >=. This makes
it possible to define types with partial orderings.
Classes or types that want to implement (in)equality tests but not
the ordering operators (i.e. unordered types) should implement ==
and !=, and raise an error for the ordering operators.
It is possible to define types whose rich comparison results are not
Boolean; e.g. a matrix type might want to return a matrix of bits
for A < B, giving elementwise comparisons. Such types should ensure
that any interpretation of their value in a Boolean context raises
an exception, e.g. by defining __nonzero__ (or the tp_nonzero slot
at the C level) to always raise an exception.
- - Complex numbers use rich comparisons to define == and != but raise
an exception for <, <=, > and >=. Unfortunately, this also means
that cmp() of two complex numbers raises an exception when the two
numbers differ. Since it is not mathematically meaningful to compare
complex numbers except for equality, I hope that this doesn't break
too much code.
- - Functions and methods now support getting and setting arbitrarily
named attributes (PEP 232). Functions have a new __dict__
(a.k.a. func_dict) which hold the function attributes. Methods get
and set attributes on their underlying im_func. It is a TypeError
to set an attribute on a bound method.
- - The xrange() object implementation has been improved so that
xrange(sys.maxint) can be used on 64-bit platforms. There's still a
limitation that in this case len(xrange(sys.maxint)) can't be
calculated, but the common idiom "for i in xrange(sys.maxint)" will
work fine as long as the index i doesn't actually reach 2**31.
(Python uses regular ints for sequence and string indices; fixing
that is much more work.)
- - Two changes to from...import:
1) "from M import X" now works even if M is not a real module; it's
basically a getattr() operation with AttributeError exceptions
changed into ImportError.
2) "from M import *" now looks for M.__all__ to decide which names to
import; if M.__all__ doesn't exist, it uses M.__dict__.keys() but
filters out names starting with '_' as before. Whether or not
__all__ exists, there's no restriction on the type of M.
- - File objects have a new method, xreadlines(). This is the fastest
way to iterate over all lines in a file:
for line in file.xreadlines():
...do something to line...
See the xreadlines module (mentioned below) for how to do this for
other file-like objects.
- - Even if you don't use file.xreadlines(), you may expect a speedup on
line-by-line input. The file.readline() method has been optimized
quite a bit in platform-specific ways: on systems (like Linux) that
support flockfile(), getc_unlocked(), and funlockfile(), those are
used by default. On systems (like Windows) without getc_unlocked(),
a complicated (but still thread-safe) method using fgets() is used by
You can force use of the fgets() method by #define'ing
USE_FGETS_IN_GETLINE at build time (it may be faster than
You can force fgets() not to be used by #define'ing
DONT_USE_FGETS_IN_GETLINE (this is the first thing to try if std test
test_bufio.py fails -- and let us know if it does!).
- - In addition, the fileinput module, while still slower than the other
methods on most platforms, has been sped up too, by using
- - Support for run-time warnings has been added, including a new
command line option (-W) to specify the disposition of warnings.
See the description of the warnings module below.
- - Extensive changes have been made to the coercion code. This mostly
affects extension modules (which can now implement mixed-type
numerical operators without having to use coercion), but
occasionally, in boundary cases the coercion semantics have changed
subtly. Since this was a terrible gray area of the language, this
is considered an improvement. Also note that __rcmp__ is no longer
supported -- instead of calling __rcmp__, __cmp__ is called with
- - In connection with the coercion changes, a new built-in singleton
object, NotImplemented is defined. This can be returned for
operations that wish to indicate they are not implemented for a
particular combination of arguments. From C, this is
- - The interpreter accepts now bytecode files on the command line even
if they do not have a .pyc or .pyo extension. On Linux, after executing
echo ':pyc:M::\x87\xc6\x0d\x0a::/usr/local/bin/python:' > /proc/sys/fs/binfmt
any byte code file can be used as an executable (i.e. as an argument
- - %[xXo] formats of negative Python longs now produce a sign
character. In 1.6 and earlier, they never produced a sign,
and raised an error if the value of the long was too large
to fit in a Python int. In 2.0, they produced a sign if and
only if too large to fit in an int. This was inconsistent
across platforms (because the size of an int varies across
platforms), and inconsistent with hex() and oct(). Example:
>>> "%x" % -0x42_
'-42' # in 2.1
'ffffffbe' # in 2.0 and before, on 32-bit machines
'-0x42L' # in all versions of Python
The behavior of %d formats for negative Python longs remains
the same as in 2.0 (although in 1.6 and before, they raised
an error if the long didn't fit in a Python int).
%u formats don't make sense for Python longs, but are allowed
and treated the same as %d in 2.1. In 2.0, a negative long
formatted via %u produced a sign if and only if too large to
fit in an int. In 1.6 and earlier, a negative long formatted
via %u raised an error if it was too big to fit in an int.
- - Dictionary objects have an odd new method, popitem(). This removes
an arbitrary item from the dictionary and returns it (in the form of
a (key, value) pair). This can be useful for algorithms that use a
dictionary as a bag of "to do" items and repeatedly need to pick one
item. Such algorithms normally end up running in quadratic time;
using popitem() they can usually be made to run in linear time.
- - In the time module, the time argument to the functions strftime,
localtime, gmtime, asctime and ctime is now optional, defaulting to
the current time (in the local timezone).
- - The ftplib module now defaults to passive mode, which is deemed a
more useful default given that clients are often inside firewalls
these days. Note that this could break if ftplib is used to connect
to a *server* that is inside a firewall, from outside; this is
expected to be a very rare situation. To fix that, you can call
- - The module site now treats .pth files not only for path configuration,
but also supports extensions to the initialization code: Lines starting
with import are executed.
- - There's a new module, warnings, which implements a mechanism for
issuing and filtering warnings. There are some new built-in
exceptions that serve as warning categories, and a new command line
option, -W, to control warnings (e.g. -Wi ignores all warnings, -We
turns warnings into errors). warnings.warn(message[, category])
issues a warning message; this can also be called from C as
- - A new module xreadlines was added. This exports a single factory
function, xreadlines(). The intention is that this code is the
absolutely fastest way to iterate over all lines in an open
for line in xreadlines.xreadlines(file):
...do something to line...
This is equivalent to the previous the speed record holder using
file.readlines(sizehint). Note that if file is a real file object
(as opposed to a file-like object), this is equivalent:
for line in file.xreadlines():
...do something to line...
- - The bisect module has new functions bisect_left, insort_left,
bisect_right and insort_right. The old names bisect and insort
are now aliases for bisect_right and insort_right. XXX_right
and XXX_left methods differ in what happens when the new element
compares equal to one or more elements already in the list: the
XXX_left methods insert to the left, the XXX_right methods to the
right. Code that doesn't care where equal elements end up should
continue to use the old, short names ("bisect" and "insort").
- - The new curses.panel module wraps the panel library that forms part
of SYSV curses and ncurses. Contributed by Thomas Gellekum.
- - The SocketServer module now sets the allow_reuse_address flag by
default in the TCPServer class.
- - A new function, sys._getframe(), returns the stack frame pointer of
the caller. This is intended only as a building block for
higher-level mechanisms such as string interpolation.
- - For Unix (and Unix-compatible) builds, configuration and building of
extension modules is now greatly automated. Rather than having to
edit the Modules/Setup file to indicate which modules should be
built and where their include files and libraries are, a
distutils-based setup.py script now takes care of building most
extension modules. All extension modules built this way are built
as shared libraries. Only a few modules that must be linked
statically are still listed in the Setup file; you won't need to
edit their configuration.
- - Python should now build out of the box on Cygwin. If it doesn't,
mail to Jason Tishler (jlt63 at users.sourceforge.net).
- - Python now always uses its own (renamed) implementation of getopt()
-- there's too much variation among C library getopt()
- - C++ compilers are better supported; the CXX macro is always set to a
C++ compiler if one is found.
- - select module: By default under Windows, a select() call
can specify no more than 64 sockets. Python now boosts
this Microsoft default to 512. If you need even more than
that, see the MS docs (you'll need to #define FD_SETSIZE
and recompile Python from source).
- - Support for Windows 3.1, DOS and OS/2 is gone. The Lib/dos-8x3
subdirectory is no more!
Guido van Rossum (home page: http://www.python.org/~guido/)