[SciPy-dev] Porting SciPy to Py3k GSOC project

David Cournapeau david@ar.media.kyoto-u.ac...
Tue Mar 24 03:21:46 CDT 2009


Stéfan van der Walt wrote:
> 2009/3/24 David Cournapeau <david@ar.media.kyoto-u.ac.jp>:
>   
>> You would need to port numpy itself before starting scipy as well. I
>> think it is fair to say that most work will be inside numpy/core - which
>> is ~ 30 000 LOC according to sloccount (wo counting comments, empty
>> lines and the like); IOW, it is massive, and there is no chance to do
>> the conversion in a couple of months unless you are very familiar with
>> numpy. I am not sure I can see a meaningful subpart of numpy/core which
>> could be ported for python 3 for a SoC.
>>     
>
> Is the situation really that dire?  How much has the C API changed
> between 2 and 3, and are these changes difficult to propagate?
>   

Talking only about the C code, here are some things which changed:
    - the buffer API is changed -> I don't know how significant this is
    - the basic C types/objects structures have changed a bit -> again,
no idea how significant this is
    - the Unicode/String unification
    - long/int unification

But I would think the main problem is that numpy simply is a big,
complicated set of C code, whose parts can't simply be done separately.
You would need to do quite a bit of changes for the code to only
compile, making bugs hard to track - and that's assuming numpy.distutils
itself won't get in the way. Then, there is the problem on how to deal
with two codebases - if we can't handle things with a few #ifdef, the
situation will be really bad. That's why I am not convinced that it
would be a good project for a GSoC. You can't try things easily.

Using cython for the C code is the advice given by the python doc itself
- although again, numpy is not the usual extension. I think almost
everything outside numpy/core should be relatively easy to convert to
cython (where easy means would take time, but could be done gradually
without impact everywhere). I don't know how usable cython would be to
define C-accessible, public extension types. But if it is, then things
can be done gradually - this can be tested by many people, etc...

I think Travis already thought a bit about the transition, but I am not
sure he has written anything about it ? he is obviously the best person
to give directions for the transition,

cheers,

David


More information about the Scipy-dev mailing list