On Thu, Feb 25, 2010 at 8:39 AM, Charles R Harris <charlesr.har...@gmail.com> wrote: > > > On Thu, Feb 25, 2010 at 1:07 AM, David Cournapeau <da...@silveregg.co.jp> > wrote: >> >> Charles R Harris wrote: >> > >> > >> > On Wed, Feb 24, 2010 at 1:15 AM, David Cournapeau <courn...@gmail.com >> > <mailto:courn...@gmail.com>> wrote: >> > >> > On Wed, Feb 24, 2010 at 1:51 PM, Charles R Harris >> > <charlesr.har...@gmail.com <mailto:charlesr.har...@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. Thanks, Kurt [1] http://tinyurl.com/yjgtpqp [2] http://www.python.org/dev/peps/pep-3118/ _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion