Well, I send here a patch obtained with 'hg diff'. Of course, before seeting up a new repo with this patch as a base, look at it for possible pitfalls regarding to style. Additionally, take care of the comments below.
- The PyNumberMethods stuff is the hard part. Some of them changed it name (nb_nonzero -> nb_bool) in py3k. I did not managed this name change yet. Other slots are gone, I basically added a flag for manage this. The realy anoying part is that some slots are UNUSED, but they are still there in the struct. Could you ask for clarifications in Python-Dev about all this crap? IMHO, all sloots should be keept, or all unused in py3k should be removed. - PyMember_New changed, I've tried to emulate this with a macro, but normal classes are not working anyway. PyClass_New is gone, I've emulated it with a call to 'type' (but in C, of course). Perhaps the class dict should be filled before calling type(name, bases, dict)?? But then I do not know how to hack cython to do that... - Finally, in the very clever part of traceback hackery, the call to Py_CodeNew receives 'filenames' created with PyUnicode_AsString. I do not know what the C preprocessor uses for enconding __FILE__ macro, it its always ASCII, then all is fine, if not, the filesystem encoding should be taken into account. Regards, On 5/8/08, Stefan Behnel <[EMAIL PROTECTED]> wrote: > Hi, > > > Lisandro Dalcin wrote: > > The last four hours (3:00 AM right now here at Argentina) I've been > > working in a patch for enabling Cython generate code working with > > Python 2.6 and Python 3.0. > > > > Until now, the generated code (at least for the full mpi4py project) > > compiles and link fine with no errors. > > > > However, I have a big problems I do not know how to 'fix' in Cython. > > It is related to unbound methods disapearing in Py3K. Then, normal > > python classes does not work, but the cdef ones are fine. > > > These are the kind of things that we planned to address at the dev1 workshop. > The C-API of Python is expected to stabilize next month, I don't know how > stable these parts currently are. > > > > > Is there any interest on this to go mainstream? > > > Sure, totally! > > > > > I was very > > conservative about the PyString/PyUnicode issue. The right one is used > > in a place-by-place base. Of course, because of this, I have to pass > > 'bytes' to MPI, and I get 'bytes' from the C calls. > > > Yes, I think this is the right way to deal with it. Python2 was very lax in > terms of semantics here, so the two have to be separated on a case-by-case > basis. > > > > > Finally, I'm completelly sure that I've not fixed all the relevant > > parts, but this is IMHO a good starting point. > > > Is it one big patch or did you/can you split it up? > > As this is potentially a big change, trac is the wrong place to discuss it. > We > should put up an official Py3 branch that people can actively work on without > impacting the main trunk, so that we can merge working stuff gradually. Can > you send a bundle against cython-devel to me and Robert for now? He can set > it up. > > Stefan > _______________________________________________ > Cython-dev mailing list > [email protected] > http://codespeak.net/mailman/listinfo/cython-dev > -- Lisandro Dalcín --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594
cython-py3k.patch
Description: Binary data
_______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
