On, Tue Apr 14, 2009, Lenard Lindstrom wrote:
Hi,
[...]
Here are some things to consider when modifying an extension module.
These differ: the init function, PyTypeObject, PyNumberMethods and
object structures. All Python 3 text strings are unicode. The PyString_
api is renamed to PyBytes_ and is for binary data or encoded text only.
All Python 3 integer are Python long. The PyInt_ functions have been
completely removed. Python 3 provides a mechanism for keeping module
state on a per-instance bases. This means global C variables should be
avoided when possible. This is not alway practical though (see base.c).
Coercing and comparison are gone. Replace with rich comparison. There
will undoubtedly be other incompatibilities.
PyFile_* has vanished nearly completely, thus it's required to use io
module calls instead. I did not implement a portable solution for the
pgreloaded rwops code yet (which is heavily used) as I did not check the
safety of fdopen() in conjunction with file objects.
Watch your filenames when using non-UTF8 and non-ASCII. You might want
to take a look at the UTF8/ASCII conversion routines in pgreloaded for
the decoding on the C API level.
Never pollute module namespaces or delete modules in Python code (as
done in __init__.py) - it will give you very bad results. In 99% of all
situations module imports should use absolute paths now and not use the
short-handed forms.
[...]
[*] For now bufferproxy will be disabled for Python 3.0. This means no
surfarray and sndarray support for numpy. The problem is the buffer
interface differs between Python 2.x and 3. I don't know by how much
exactly, maybe not enough to be a concern. If the differences are
significant one solution is to replace the buffer interface with the
array interface. The advantage is the array interface should be the same
for Python 2.x and 3. One disadvantage is the array interface may be
phased out over time in favor of the new buffer interface. An advantage
of the new buffer interface is it provides explicit releasing of a
buffer object. This means a surface can be unlocked with a callback
rather than a bufferproxy's deallocator.
The 3k buffer interface is implemented in pgreloaded's bufferproxy class
and should be usable. One advantage of the bufferproxy is that we do not
enforce two different behaviours on the user - the bufferproxy wraps
that up while providing transparent buffer support for more specialised
operations.
Anything else could be directly implemented in a version-specific manner
on the class level. I would not want to have any compatibility for those
cases as the APIs differ way too much (memoryview vs. old-style array,
buffer, etc.).
Regards
Marcus