[Numpy-discussion] How to test f2py?

David Cournapeau david@silveregg.co...
Thu Feb 25 02:07:24 CST 2010

Charles R Harris wrote:
> On Wed, Feb 24, 2010 at 1:15 AM, David Cournapeau <cournape@gmail.com 
> <mailto:cournape@gmail.com>> wrote:
>     On Wed, Feb 24, 2010 at 1:51 PM, Charles R Harris
>     <charlesr.harris@gmail.com <mailto:charlesr.harris@gmail.com>> wrote:
>      >
>      > Boy, that code is *old*, it still uses Numeric ;) I don't think
>     it can
>      > really be considered a test suite, it needs lotsa love and it
>     needs to get
>      > installed. Anyway, f2py with py3k turns out to have string
>     problems, and I
>      > expect other type problems, so there is considerable work that
>     needs to be
>      > done to bring it up to snuff. Sounds like gsoc material. I'm not
>     going to
>      > worry about it any more until later.
>     If it would take a GSoC to make it up to work, it may be time better
>     spent on improving fwrap.
> How far along is fwrap? It looks like f2py2e was a project that got 
> dropped half way through an update, some exceptions are of the wrong 
> type, the tests need a complete rewrite, etc.

Well, the f2py as included in numpy is at least stable, since it has 
been used with little to no change for scipy the last few years, whereas 
fwrap is largely untested on the scale of something like scipy. I was 
suggesting to look into fwrap *if* f2py would be really hard to make to 
work for python 3.x.

What worries me for f2py is not so much the python code (at worst, we 
could hack something to call f2py through python 2.x for the 3.x build - 
numscons runs f2py out of process for // build) as much as the generated 
C code. Debugging code generators is rarely fun in my experience :)



More information about the NumPy-Discussion mailing list