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
Attachment:
pgpXnPTJY0stZ.pgp
Description: PGP signature