15 Porting to Python 2.5

#
15 Porting to Python 2.5

This section lists previously described changes that may require changes to your code:

- ASCII is now the default encoding for modules. It's now a syntax error if a module contains string literals with 8-bit characters but doesn't have an encoding declaration. In Python 2.4 this triggered a warning, not a syntax error.

- Previously, the `gi_frame` attribute of a generator was always a frame object. Because of the PEP 342 changes described in section 7, it's now possible for `gi_frame` to be `None`.

- A new warning, `UnicodeWarning`, is triggered when you attempt to compare a Unicode string and an 8-bit string that can't be converted to Unicode using the default ASCII encoding. Previously such comparisons would raise a `UnicodeDecodeError` exception.

- Library: the `csv` module is now stricter about multi-line quoted fields. If your files contain newlines embedded within fields, the input should be split into lines in a manner which preserves the newline characters.

- Library: the `locale` module's `format()` function's would previously accept any string as long as no more than one %char specifier appeared. In Python 2.5, the argument must be exactly one %char specifier with no surrounding text.

- Library: The `pickle` and `cPickle` modules no longer accept a return value of `None` from the `__reduce__()` method; the method must return a tuple of arguments instead. The modules also no longer accept the deprecated bin keyword parameter.

- Library: The `SimpleXMLRPCServer` and `DocXMLRPCServer` classes now have a `rpc_paths` attribute that constrains XML-RPC operations to a limited set of URL paths; the default is to allow only `'/'` and `'/RPC2'`. Setting `rpc_paths` to `None` or an empty tuple disables this path checking.

- C API: Many functions now use `Py_ssize_t` instead of `int` to allow processing more data on 64-bit machines. Extension code may need to make the same change to avoid warnings and to support 64-bit machines. See the earlier section 10 for a discussion of this change.

- C API: The obmalloc changes mean that you must be careful to not mix usage of the `PyMem_*()` and `PyObject_*()` families of functions. Memory allocated with one family's `*_Malloc()` must be freed with the corresponding family's `*_Free()` function.