[SciPy-dev] NumPy f2py GSOC project

Dag Sverre Seljebotn dagss at student.matnat.uio.no
Thu Mar 26 18:47:38 EDT 2009


Charles R Harris wrote:
> On Thu, Mar 26, 2009 at 2:44 PM, Kurt Smith <kwmsmith at gmail.com 
> <mailto:kwmsmith at gmail.com>> wrote:
> 
>     2009/3/26 ross smith <rjsm at umich.edu <mailto:rjsm at umich.edu>>:
>      > When I looked at that one,  It seemed to me like they are trying
>     to use it
>      > to bind fortran and C together with only a thin, fairly
>     transparent python
>      > layer in the middle.
> 
>     Actually, it's more like binding Fortran to Python/Cython and
>     enhancing the ability to pass numpy arrays and python buffer objects
>     to external fortran code.  The "f2c" capability (with fortran 2003 ISO
>     C bindings) is just gravy ;-)  The "python layer" will likely have to
>     do a good bit of work to make the passing of arrays seamless to the
>     user and minimize the copying of arrays.
> 
> 
> I'm a bit confused as to how these two projects relate each other. 
> Should they be coordinated or can they stand separately? What would be 
> the upshot? If f2py is updated, then presumably it could act as a drop 
> in replacement for the current f2py. Would the cython project have that 
> same effect?

Kurt's project/Cython-Fortran:
  - Only uses the parser from f2py, but may provide some 
improvements/patches for that part. There's a good chance 3rd gen f2py 
will be chosen in which case there is probably no overlap codewise (if 
Ross' project is for 2nd gen f2py).

  - A drop-in replacement for f2py is not a goal. It could be for 
projects where no changes are made to generated .pyf files, but will not 
become one for custom-written .pyf files

  - Will facilitate wrapping Fortran modules using Cython in the same 
way one uses Cython for C (i.e. if non-trivial wrapping is needed one 
writes Cython code rather than a modify a .pyf file).

If Ross' project involves work on the same parser (likely this means the 
3rd gen f2py) then some coordination would be in order in the parser; 
this could rather trivially be resolved. Otherwise there doesn't seem to 
be any overlap.

As far as I can gather, that is. But I must admit that I don't really 
understand Ross' project. What part will be ported to Cython? As I 
understand it, a) f2py itself is entirely written in Python already, b) 
it generates a C module much like Cython does, which must currently be 
kept Py2 because of the NumPy dependency.

If the plan is to switch to a Cython backend, so that f2py starts 
*generating* Cython code, then there's somewhat more overlap in goals. 
(But that would break existing .pyf files as they can contain free-form 
C code?)

-- 
Dag Sverre



More information about the SciPy-Dev mailing list