On May 8, 2008, at 8:33 AM, Lisandro Dalcin wrote: > Well, I send here a patch obtained with 'hg diff'.
Thanks. I briefly glanced at it and it looks good. What you probably want to do is commit and then export the patch (that way it will have some history attached, and you'll get credit for it.) FYI, I am preparing for my general exams that I take in a couple of weeks, so won't have tons of time to put into Cython in the near future, but this looks like really good work. > 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. One remark I had is that perhaps more care needs to be done with "PyInt_CheckExact" as in Py2 this implies that the size fits into a long, so it's not quite the same as PyLong_CheckExact. > - 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. Could you elaborate a bit more on what you mean by "unused?" If they're still in the struct, I'd think we would need to keep them so it has the right size/layout, right? > - 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... Filling the dict ahead of time might actually work better...one would execute the body in a temporary scope and then construct the class. This would bring things more in line with how Python does things. > - 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. I actually have no idea on this one--maybe there's some system call that can give this information? Stefan would probably know better than me. > > 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>_______________________________________________ > Cython-dev mailing list > [email protected] > http://codespeak.net/mailman/listinfo/cython-dev _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
