On Sat, Jul 25, 2009 at 8:01 PM, Shane Hathaway<sh...@hathawaymix.org> wrote: > Hanno Schlichting wrote: >> >> I kind of suspect that we are seeing the results of >> http://www.python.org/dev/peps/pep-0353 though. > > That is very likely. BTW, that PEP links to a handy tool that reveals most > 64 bit portability issues in Python-oriented C code.
Right, I've given that a shot and it reports plenty of problems for Acquisition.c for example. In addition to the general compiler warnings it spits out, which don't tell me much. >> From what I understand we need to change code in C extension modules >> following the instructions in that PEP, to be able to run code >> reliably on 64-bit platforms. To my knowledge nobody changed any C >> code in Zope yet to do so. > > We fixed the C portability problems in Zope 3 a while back, but it seems we > didn't fix the extensions that are specific to Zope 2. How thorough has that been? I can see the Py_ssize_t in some of the c files in zope.* packages, but looking for example at: http://svn.zope.org/zope.proxy/trunk/src/zope/proxy/_zope_proxy_proxy.c?rev=95468&view=markup I see a stuff like this: PyObject * WrapperType_Lookup(PyTypeObject *type, PyObject *name) { int i, n; [...] n = PyTuple_GET_SIZE(mro) - 1; [...] } where PyTuple_GET_SIZE is defined to return a Py_ssize_t and not an int. Either I misunderstand something here or I was just "lucky" to find something like this as my first test. >> The other interesting bit to this is, that it seems doable but hard to >> do these changes while preserving compatibility with Python 2.4. These >> changes along with the definition of "Py_ssize_t" were introduced into >> Python 2.5. > > Preprocessor macros solve that fairly cleanly, actually: > > #ifndef Py_ssize_t > #define Py_ssize_t int > #endif Ah ok. I was more concerned about the function pointer changes. intargfunc to ssizeargfunc and so on. I wasn't sure if these are as easy to redefine as simple data types. >> At this point I think we need to declare 64-bit platforms as >> unsupported. Hopefully people with the right kind of knowledge would >> like to step up and start working on these issues. > > I just checked in some code that solves the portability problem in > zope.index, although I haven't created a release. It looks like the > Acquisition module needs some 64 bit TLC. Cool! I kinda suspect that specific code is also somewhere in Zope2 in the PluginIndexes where it has been ported from recently. Hanno _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
