[Numpy-discussion] How to test f2py?

Kurt Smith kwmsmith@gmail....
Thu Feb 25 12:15:16 CST 2010

On Thu, Feb 25, 2010 at 8:39 AM, Charles R Harris
<charlesr.harris@gmail.com> wrote:
> On Thu, Feb 25, 2010 at 1:07 AM, David Cournapeau <david@silveregg.co.jp>
> wrote:
>> 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 :)
> It might not be too difficult to get f2py running with Python3.x. At first
> try there were some places in the generated code that called Python string
> functions that have gone away, but those should be fixable without too much
> trouble. There may be a few other troublesome spots, but I don't think
> things will be that difficult.
> I'm more concerned for the long run. The code needs a fixed up test suite,
> it needs documentation, and it needs a maintainer, at least for a while.

Glad I came across this thread :)

I'm the developer of fwrap.  It is coming along, but will be at least
a month, likely two before the first release.  (The main areas that
need some TLC are the fortran parser and the build system; the build
system will leverage numpy's distutils unless waf is easy to get
working.) The first release will cover a large portion of f2py's
current functionality, but I don't plan on having python callbacks
working then.  Callbacks will be a part of the second release.

An issue that you should be aware of is that fwrap will not work with
f77, and requires gfortran 4.3.3 or greater, since it uses C
interoperability features not available in f77.  (Fwrap will work with
any 'modern' fortran compiler that has the basic C interoperability
features implemented.  Looking around it appears that all of them do
have the basic set necessary, see [1].  So this only excludes f77.)

Fwrap by design will work seamlessly with numpy arrays and PEP 3118
buffers [2], and will support Python 2.4 - 3.x (thanks in large part
to its leveraging Cython for the C wrappers).  It has an expanding
testsuite (unittests & acceptance tests) and I hope it's designed
clearly enough to encourage contributions after the first release.
You can trust its C generation as far as you trust Cython's C
generation.  Although I guess you'll have to trust fwrap's Fortran &
Cython generation :)  But like I said, it has a testsuite that has
everything covered.

So, to recap:  fwrap will do much of what you want, but it will
exclude f77, and has a Cython dependency.  It won't have callbacks
working right away, but will by the second release.  When its matured
enough I'd like to get fwrap to generate the bindings for scipy.  Once
it gets to that point (sometime this summer) we can talk :)  As far as
the 'long run' goes:  fwrap has and will have a test suite,
documentation and a maintainer, so those are covered.

For more information:

Fwrap's blog:  http://fortrancython.wordpress.com/

Fwrap's bitbucket repository:  http://bitbucket.org/kwmsmith/fwrap-dev/

...which is a mirror of it's cython repo:  http://hg.cython.org/fwrap-dev/

Feel free to contact me with any more questions.



[1] http://tinyurl.com/yjgtpqp
[2] http://www.python.org/dev/peps/pep-3118/

More information about the NumPy-Discussion mailing list