\documentclass{howto}

\title{What's New in Python 1.6}
\release{0.01}
\author{A.M. Kuchling and Moshe Zadka}
\authoraddress{\email{amk1@bigfoot.com}, \email{moshez@math.huji.ac.il} }
\begin{document}
\maketitle\tableofcontents

\section{Introduction}

A new release of Python, version 1.6, will be released some time this
summer.  Alpha versions are already available from
\url{http://www.python.org/1.6/}.  This article talks about the
exciting new features in 1.6, highlights some other useful changes,
and points out a few incompatible changes that may require rewriting
code.

Python's development never completely stops between releases, and a
steady flow of bug fixes and improvements are always being submitted.
A host of minor fixes, a few optimizations, additional docstrings, and
better error messages went into 1.6; to list them all would be
impossible, but they're certainly significant.  Consult the
publicly-available CVS logs if you want to see the full list.

% ======================================================================
\section{Unicode}

The largest new feature in Python 1.6 is a new fundamental data type:
Unicode strings.  Unicode uses 16-bit numbers to represent characters
instead of the 8-bit number used by ASCII, meaning that 65,536
distinct characters can be supported.

The final interface for Unicode support was arrived at through
countless often-stormy discussions on the python-dev mailing list.  A
detailed explanation of the interface is in \file{Misc/unicode.txt} in
the Python source distribution; this file is also available on the Web
at \url{http://starship.python.net/crew/lemburg/unicode-proposal.txt}.
This article will simply cover the most significant points from the
full interface.

In Python source code, Unicode strings are written as
\code{u"string"}.  Arbitrary Unicode characters can be written using a
new escape sequence, \code{\\u\var{HHHH}}, where \var{HHHH} is a
4-digit hexadecimal number from 0000 to FFFF.  The existing
\code{\\x\var{HHHH}} escape sequence can also be used, and octal
escapes can be used for characters up to U+01FF, which is represented
by \code{\\777}.

Unicode strings, just like regular strings, are an immutable sequence
type, so they can be indexed and sliced.  They also have an
\method{encode( \optional{encoding} )} method that returns an 8-bit
string in the desired encoding.  Encodings are named by strings, such
as \code{'ascii'}, \code{'utf-8'}, \code{'iso-8859-1'}, or whatever.
A codec API is defined for implementing and registering new encodings
that are then available throughout a Python program.  If an encoding
isn't specified, the default encoding is always 7-bit ASCII.  (XXX is
that the current default encoding?)

Combining 8-bit and Unicode strings always coerces to Unicode, using
the default ASCII encoding; the result of \code{'a' + u'bc'} is
\code{'abc'}.

New built-in functions have been added, and existing built-ins
modified to support Unicode:

\begin{itemize}
\item \code{unichr(\var{ch})} returns a Unicode string 1 character
long, containing the character \var{ch}.

\item \code{ord(\var{u})}, where \var{u} is a 1-character regular or Unicode string, returns the number of the character as an integer.

\item \code{unicode(\var{string}, \optional{encoding = '\var{encoding
string}', } \optional{errors = 'strict' \textit{or} 'ignore'
\textit{or} 'replace'} ) } creates a Unicode string from an 8-bit
string.  \code{encoding} is a string naming the encoding to use.

The \code{errors} parameter specifies the treatment of characters that
are invalid for the current encoding; passing \code{'strict'} as the
value causes an exception to be raised on any encoding error, while
\code{'ignore'} causes errors to be silently ignored and
\code{'replace'} uses U+FFFD, the official replacement character, in
case of any problems.

\end{itemize}

A new module, \module{unicodedata}, provides an interface to Unicode
character properties.  For example, \code{unicodedata.category(u'A')}
returns the 2-character string 'Lu', the 'L' denoting it's a letter,
and 'u' meaning that it's uppercase.
\code{u.bidirectional(u'\x0660')} returns 'AN', meaning that U+0660 is
an Arabic number.

The \module{codecs} module contains coders and decoders for various
encodings, along with functions to register new encodings and look up
existing ones.  Unless you want to implement a new encoding, you'll
most often use the \function{codecs.lookup(\var{encoding})} function,
which returns a 4-element tuple: \code{(\var{encode_func},
\var{decode_func}, \var{stream_reader}, \var{stream_writer}.

\begin{itemize}
\item \var{encode_func} is a function that takes a Unicode string, and
returns a 2-tuple \code{(\var{string}, \var{length})}.  \var{string}
is an 8-bit string containing a portion (perhaps all) of the Unicode
string converted into the given encoding, and \var{length} tells you how much of the Unicode string was converted.

\item \var{decode_func} is the mirror of \var{encode_func}, 
taking a Unicode string and
returns a 2-tuple \code{(\var{ustring}, \var{length})} containing a Unicode string
and \var{length} telling you how much of the string was consumed.

\item \var{stream_reader} is a class that supports decoding input from
a stream.  \var{stream_reader(\var{file_obj})} returns an object that
supports the \method{read()}, \method{readline()}, and
\method{readlines()} methods.  These methods will all translate from
the given encoding and return Unicode strings.

\item \var{stream_writer}, similarly, is a class that supports
encoding output to a stream.  \var{stream_writer(\var{file_obj})}
returns an object that supports the \method{write()} and 
\method{writelines()} methods.  These methods expect Unicode strings, translating them to the given encoding on output.
\end{itemize}

For example, the following code writes a Unicode string into a file, 
encoding it as UTF-8:

\begin{verbatim}
import codecs

unistr = u'\u0660\u2000ab ...'

(UTF8_encode, UTF8_decode,
 UTF8_streamreader, UTF8_streamwriter) = codecs.lookup('UTF-8')

output = UTF8_streamwriter( open( '/tmp/output', 'wb') )
output.write( unistr )
output.close()
\end{verbatim}

The following code would then read UTF-8 input from the file:

\begin{verbatim}
input = UTF8_streamread( open( '/tmp/output', 'rb') )
print repr(input.read())
input.close()
\end{verbatim}

Unicode-aware regular expressions are available through the
\module{re} module, which has a new underlying implementation called
SRE written by Fredrik Lundh of Secret Labs AB. 

% Added -U command line option.  With the option enabled the Python
% compiler interprets all "..."  strings as u"..." (same with r"..." and
% ur"...").  (XXX Is this just for experimenting?)

% ======================================================================
\section{Distutils: Making Modules Easy to Install}

Before Python 1.6, installing modules was a tedious affair -- there
was no way to figure out automatically where Python is installed, or
what compiler options to use for extension modules.  Software authors
had to go through an ardous ritual of editing Makefiles and
configuration files, which only really work on Unix and leave Windows
and MacOS unsupported.  Software users faced wildly differing
installation instructions 

The SIG for distribution utilities, shepherded by Greg Ward, has
created the Distutils, a system to make package installation much
easier.  They form the \package{distutils} package, a new part of
Python's standard library. In the best case, installing a Python
module from source will require the same steps: first you simply mean
unpack the tarball or zip archive, and the run ``\code{python setup.py
install}''.  The platform will be automatically detected, the compiler
will be recognized, C extension modules will be compiled, and the
distribution installed into the proper directory.  Optional
command-line arguments provide more control over the installation
process, the distutils package offers many places to override defaults
-- separating the build from the install, building or installing in
non-default directories, and more.

In order to use the Distutils, you need to write a \file{setup.py}
script.  For the simple case, when the software contains only .py
files, a minimal \file{setup.py} can be just a few lines long:

\begin{verbatim}
from distutils.core import setup
setup (name = "foo", version = "1.0", 
       py_modules = ["module1", "module2"])
\end{verbatim}

The \file{setup.py} file isn't much more complicated if the software
consists of a few packages:

\begin{verbatim}
from distutils.core import setup
setup (name = "foo", version = "1.0", 
       packages = ["package", "package.subpackage"])
\end{verbatim}

A C extension can be the most complicated case; here's an example taken from 
the PyXML package:


\begin{verbatim}
from distutils.core import setup, Extension

expat_extension = Extension('xml.parsers.pyexpat',
	define_macros = [('XML_NS', None)],
	include_dirs = [ 'extensions/expat/xmltok',
	                 'extensions/expat/xmlparse' ],
	sources = [ 'extensions/pyexpat.c',
	            'extensions/expat/xmltok/xmltok.c',
 		    'extensions/expat/xmltok/xmlrole.c',
                  ]
       )
setup (name = "PyXML", version = "0.5.4", 
       ext_modules =[ expat_extension ] )
	        
\end{verbatim}

The Distutils can also take care of creating source and binary
distributions.  The ``sdist'' command, run by ``\code{python setup.py
sdist}', builds a source distribution such as \file{foo-1.0.tar.gz}.
Adding new commands isn't difficult, and a ``bdist_rpm'' command has
already been contributed to create an RPM distribution for the
software.  Commands to create Windows installer programs, Debian
packages, and Solaris .pkg files have been discussed and are in
various stages of development.

All this is documented in a new manual, \textit{Distributing Python
Modules}.

% ======================================================================
\section{String Methods}

Until now string-manipulation functionality was in the \module{string}
Python module, which was usually a front-end for the \module{strop}
module written in C.  The addition of Unicode posed a difficulty for
the \module{strop} module, because the functions would all need to be
rewritten in order to accept either 8-bit or Unicode strings.  For
functions such as \function{string.replace()}, which takes 3 string
arguments, that means eight possible permutations, and correspondingly
complicated code.

Instead, Python 1.6 pushes the problem onto the string type, making
string manipulation functionality available through methods on both
8-bit strings and Unicode strings.  

\begin{verbatim}
>>> 'andrew'.capitalize()
'Andrew'
>>> 'hostname'.replace('os', 'linux')
'hlinuxtname'
>>> 'moshe'.find('sh')
2
\end{verbatim}

One thing that hasn't changed, April Fools' jokes notwithstanding, is
that Python strings are immutable. Thus, the string methods return new
strings, and do not modify the string on which they operate.

The old \module{string} module is still around for backwards
compatibility, but it mostly acts as a front-end to the new string
methods.

Two methods which have no parallel in pre-1.6 versions, although they
did exist in JPython for quite some time, are \method{startswith()}
and \method{endswith}.  \code{s.startswith(t)} is equivalent to \code{s[:len(t)]
== t}, while \code{s.endswith(t)} is equivalent to \code{s[-len(t):] == t}.

(XXX what'll happen to join?)  One other method which deserves special
mention is \method{join}.  The \method{join} method of a list receives
one parameter, a sequence of strings, and is equivalent to the
\function{string.join} function from the old \module{string} module,
with the arguments reversed. In other words, \code{s.join(seq)} is
equivalent to the old \code{string.join(seq, s)}.

Some list methods, such as \method{find}, \method{index},
\method{count}, \method{rindex}, and \method{rfind} are now available
on strings, allowing some nice polymorphic code which can deal with
either lists or strings without changes.

% ======================================================================
\section{Porting to 1.6}

New Python releases try hard to be compatible with previous releases,
and the record has been pretty good.  However, some changes are
considered useful enough, often fixing initial design decisions that
turned to be actively mistaken, that breaking backward compatibility
can't always be avoided.  This section lists the changes in Python 1.6
that may cause old Python code to break.

The change which will probably break the most code is tightening up
the arguments accepted by some methods.  Some methods would take
multiple arguments and treat them as a tuple, particularly various
list methods such as \method{.append()}, \method{.insert()},
\method{remove()}, and \method{.count()}.
(XXX did anyone ever call the last 2 methods with multiple args?)
In earlier versions of Python, if \code{L} is a list, \code{L.append(
1,2 )} appends the tuple \code{(1,2)} to the list.  In Python 1.6 this
causes a \exception{TypeError} exception to be raised, with the
message: 'append requires exactly 1 argument; 2 given'.  The fix is to
simply add an extra set of parentheses to pass both values as a tuple: 
\code{L.append( (1,2) )}.

The earlier versions of these methods were more forgiving because they
used an old function in Python's C interface to parse their arguments;
1.6 modernizes them to use \function{PyArg_ParseTuple}, the current
argument parsing function, which provides more helpful error messages
and treats multi-argument calls as errors.  If you absolutely must use
1.6 but can't fix your code, you can edit \file{Objects/listobject.c}
and define the preprocessor symbol \code{NO_STRICT_LIST_APPEND} to
preserve the old behaviour; this isn't recommended.

Some of the functions in the \module{socket} module are still
forgiving in this way.  For example, \function{socket.connect(
('hostname', 25) )} is the correct form, passing a tuple representing
an IP address, but
\function{socket.connect( 'hostname', 25 )} also
works. \function{socket.connect_ex()} and \function{socket.bind()} are
similarly easy-going.  1.6alpha1 tightened these functions up, but
because the documentation actually used the erroneous multiple
argument form, many people wrote code which will break.  So for
the\module{socket} module, the documentation was fixed and the
multiple argument form is simply marked as deprecated; it'll be
removed in a future Python version.  

Some work has been done to make integers and long integers a bit more
interchangeable.  In 1.5.2, large-file support was added for Solaris,
to allow reading files larger than 2Gb; this made the \method{tell()}
method of file objects return a long integer instead of a regular
integer.  Some code would subtract two file offsets and attempt to use
the result to multiply a sequence or slice a string, but this raised a
\exception{TypeError}.   In 1.6, long integers can be used to multiply
or slice a sequence, and it'll behave as you'd intuitively expect it to; 
\code{3L * 'abc'} produces 'abcabcabc', and 
\code{ (0,1,2,3)[2L:4L]} produces (2,3). Long integers can also be
used in various new places where previously only integers were
accepted, such as in the \method{seek()} method of file objects.

The subtlest long integer change of all is that the \function{str()}
of a long integer no longer has a trailing 'L' character, though
\function{repr()} still includes it.  The 'L' annoyed many people who
wanted to print long integers that looked just like regular integers,
since they had to go out of their way to chop off the character.  This
is no longer a problem in 1.6, but code which assumes the 'L' is
there, and does \code{str(longval)[:-1]} will now lose the final
digit.  

Taking the \function{repr()} of a float now uses a different
formatting precision than \function{str()}.  \function{repr()} uses
``%.17g'' format string for C's \function{sprintf()}, while
\function{str()} uses ``%.12g'' as before.  The effect is that
\function{repr()} may occasionally show more decimal places than 
\function{str()}, for numbers 
XXX need example value here to demonstrate problem.


% ======================================================================
\section{Core Changes}

Various minor changes have been made to Python's syntax and built-in
functions.  None of the changes are very far-reaching, but they're
handy conveniences.

A change to syntax makes it more convenient to call a given function
with a tuple of arguments and/or a dictionary of keyword arguments.
In Python 1.5 and earlier, you do this with the \builtin{apply()}
built-in function: \code{apply(f, \var{args}, \var{kw})} calls the
function \function{f()} with the argument tuple \var{args} and the
keyword arguments in the dictionary \var{kw}.  Thanks to a patch from
Greg Ewing, 1.6 adds \code{f(*\var{args}, **\var{kw})} as a shorter
and clearer way to achieve the same effect.  This syntax is
symmetrical with the syntax for defining functions:

\begin{verbatim}
def f(*args, **kw):
    # args is a tuple of positional args,
    # kw is a dictionary of keyword args
    ...
\end{verbatim}

A new format style is available when using the \operator{\%} operator.
'\%r' will insert the \function{repr()} of its argument.  This was
also added from symmetry considerations, this time for symmetry with
the existing '\%s' format style, which inserts the \function{str()} of
its argument.  For example, \code{'%r %s' % ('abc', 'abc')} returns a
string containing \verb|'abc' abc|.

The \builtin{int()} and \builtin{long()} functions now accept an
optional ``base'' parameter when the first argument is a string.
\code{int('123', 10)} returns 123, while \code{int('123', 16)} returns
291.  \code{int(123, 16)} raises a \exception{TypeError} exception
with the message ``can't convert non-string with explicit base''.

Previously there was no way to implement a class that overrode
Python's built-in \operator{in} operator and implemented a custom
version.  \code{\var{obj} in \var{seq}} returns true if \var{obj} is
present in the sequence \var{seq}; Python computes this by simply
trying every index of the sequence until either \var{obj} is found or
an \exception{IndexError} is encountered.  Moshe Zadka contributed a
patch which adds a \method{__contains__} magic method for providing a
custom implementation for \operator{in}. Additionally, new built-in objects
can define what \operator{in} means for them via a new slot in the sequence
protocol.

Earlier versions of Python used a recursive algorithm for deleting
objects.  Deeply nested data structures could cause the interpreter to
fill up the C stack and crash; Christian Tismer rewrote the deletion
logic to fix this problem.  On a related note, comparing recursive
objects recursed infinitely and crashed; Jeremy Hylton rewrote the
code to no longer crash, producing a useful result instead.  For
example, after this code:

\begin{verbatim}
a = []
b = []
a.append(a)
b.append(b)
\end{verbatim}

The comparison \code{a==b} returns true, because the two recursive
data structures are isomorphic.
\footnote{See the thread ``trashcan and PR\#7'' in the April 2000 archives of the python-dev mailing list for the discussion leading up to this implementation, and some useful relevant links.
%http://www.python.org/pipermail/python-dev/2000-April/004834.html
}

Work has been done on porting Python to 64-bit Windows on the Itanium
processor, mostly by Trent Mick of ActiveState.  (Confusingly, \code{sys.platform} is still \code{'win32'} on
Win64 because it seems that for ease of porting, MS Visual C++ treats code
as 32 bit.
)  PythonWin also supports Windows CE; see the Python CE page at
\url{http://www.python.net/crew/mhammond/ce/} for more information.

An attempt has been made to alleviate one of Python's warts, the
often-confusing \exception{NameError} exception when code refers to a
local variable before the variable has been assigned a value.  For
example, the following code raises an exception on the \keyword{print}
statement in both 1.5.2 and 1.6; in 1.5.2 a \exception{NameError}
exception is raised, while 1.6 raises \exception{UnboundLocalError}.

\begin{verbatim}
def f():
    print "i=",i
    i = i + 1 
f()
\end{verbatim}

A new variable holding more detailed version information has been
added to the \module{sys} module.  \code{sys.version_info} is a tuple
\code{(\var{major}, \var{minor}, \var{micro}, \var{level},
\var{serial})} For example, in 1.6a2 \code{sys.version_info} is
\code{(1, 6, 0, 'alpha', 2)}.  \var{level} is a string such as
\code{"alpha"}, \code{"beta"}, or \code{""} for a final release.

% ======================================================================
\section{Extending/Embedding Changes}

Some of the changes are under the covers, and will only be apparent to
people writing C extension modules, or embedding a Python interpreter
in a larger application.  If you aren't dealing with Python's C API,
you can safely skip this section.

Users of Jim Fulton's ExtensionClass module will be pleased to find
out that hooks have been added so that ExtensionClasses are now
supported by \function{isinstance()} and \function{issubclass()}.
This means you no longer have to remember to write code such as
\code{if type(obj) == myExtensionClass}, but can use the more natural
\code{if isinstance(obj, myExtensionClass)}.

The \file{Python/importdl.c} file, which was a mass of #ifdefs to
support dynamic loading on many different platforms, was cleaned up
are reorganized by Greg Stein.  \file{importdl.c} is now quite small,
and platform-specific code has been moved into a bunch of
\file{Python/dynload_*.c} files.  

Vladimir Marangozov's long-awaited malloc restructuring was completed,
to make it easy to have the Python interpreter use a custom allocator
instead of C's standard \function{malloc()}.  For documentation, read
the comments in \file{Include/mymalloc.h} and
\file{Include/objimpl.h}.  For the lengthy discussions during which
the interface was hammered out, see the Web archives of the 'patches'
and 'python-dev' lists at python.org.

Recent versions of the GUSI (XXX what is GUSI?)
development environment for MacOS support POSIX threads.  Therefore,
POSIX threads are now supported on the Macintosh too.  Threading
support using the user-space GNU pth library was also contributed.

Threading support on Windows was enhanced, too.  Windows supports
thread locks that use kernel objects only in case of contention; in
the common case when there's no contention, they use simpler functions
which are an order of magnitude faster.  A threaded version of Python
1.5.2 on NT is twice as slow as an unthreaded version; with the 1.6
changes, the difference is only 10\%.  These improvements were
contributed by Yakov Markovitch.

% ======================================================================
\section{Module changes}

Lots of improvements and bugfixes were made to Python's extensive
standard library; some of the affected modules include
\module{readline}, \module{ConfigParser}, \module{cgi},
\module{calendar}, \module{posix}, \module{readline}, \module{xmllib},
\module{aifc}, \module{chunk, wave}, \module{random}, \module{shelve},
and \module{nntplib}.  Consult the CVS logs for the exact
patch-by-patch details.  

Brian Gallew contributed OpenSSL support for the \module{socket}
module.  When compiling Python, you can edit \file{Modules/Setup} to
include SSL support.  When enabled, an additional function
\function{socket.ssl(\var{socket}, \var{keyfile}, \var{certfile})},
which takes a socket object and returns an SSL socket.  When SSL
support is available, the \module{httplib} and \module{urllib} modules
will support ``https://'' URLs.

The \module{Tkinter} module now supports Tcl/Tk version 8.1, 8.2, or
8.3, and support for the older 7.x versions has been dropped.  The
Tkinter module also supports displaying Unicode strings in Tk
widgets.  

The \module{curses} module has been greatly extended, starting from
Oliver Andrich's enhanced version, to provide many additional
functions from ncurses and SYSV curses, such as colour, alternative
character set support, pads, and other new features.  This means the
module is no longer compatible with operating systems that only have
BSD curses, but there don't seem to be any currently maintained OSes
that fall into this category.

XXX re - changed to be a frontend to sre

% ======================================================================
\section{New modules}

winreg - Windows registry interface.
Distutils - tools for distributing Python modules
PyExpat - interface to Expat XML parser
robotparser - parse a robots.txt file (for writing web spiders)
linuxaudio - audio for Linux
mmap - treat a file as a memory buffer
filecmp - supersedes the old cmp.py and dircmp.py modules
tabnanny - check Python sources for tab-width dependance
sre -  regular expressions (fast, supports unicode)
unicode - support for unicode
codecs - support for Unicode encoders/decoders

% ======================================================================
\section{IDLE Improvements}

XXX IDLE -- complete overhaul; what are the changes?

% ======================================================================
\section{Deleted and Deprecated Modules}

XXX stdwin, others?

\end{document}