[SciPy-dev] F2PY future

Ondrej Certik ondrej@certik...
Mon Apr 14 04:10:57 CDT 2008


On Mon, Apr 14, 2008 at 10:59 AM, Pearu Peterson <pearu@cens.ioc.ee> wrote:
>
>  Ondrej Certik wrote:
>
>  > Let me add, that I, as the user of f2py and also right now one of the
>  > maintainers of the numpy/scipy packages in Debian, I find it really
>  > bad, if the tools
>  > move around from a package to package so often. It makes thing really
>  > hard to package and follow.
>  >
>  > As an example, Debian sarge, Debian etch and Debian lenny all have
>  > different ways how to install and work with numpy, scipy and f2py.
>  > This is bad, because everyone has to relearn all the time and also if
>  > you, say, install scipy from sources (because the released version is
>  > too old), it's freaking hard, because I cannot just take use the same
>  > tricks as in unstable, because things has moved around since etch.
>   >
>  > So my suggestion is either choose numpy, or your own f2py package, but
>  > stick to it forever. :)
>
>  I agree with you.
>
>
>  > Also, how are you going to handle and package this g3 f2py? Cannot it
>  > be just part of the regular f2py?
>
>  In short run, g3 f2py will be developed separately from numpy because
>  g3 f2py requires lots of work and I don't want to disturb the stability
>  of numpy svn. When g3 f2py will become usable, it's code can be copied
>  to numpy tree as it is now. So, g3 f2py can be distributed with numpy
>  together with the stable f2py and for users it is a matter of using
>  f2py command line flags --2d-{numeric, numpy. numarray} --g3-numpy
>  to choose which implementation of f2py will be used for wrapping.
>
>  In long run, the future of f2py packaging depends on what will be
>  numpy future policy regarding various extension generation
>  and other non-array related tools. It is clear
>  that when f2py (and numpy.distutils, etc) is shipped with numpy,
>  supporting scipy is considerably easier. That is why f2py,
>  scipy_distutils, and scipy_testing were included to numpy in
>  the first place.
>
>  On the other hand, cleaning up numpy from non-array stuff
>  has an advantage of making numpy easier for python developers to accept
>  it as a part of std library. So, I am not sure that I alone can give a
>  definite promise that the packaging of f2py will never change in future.
>  If the numpy cleanup decision will be made, it must take into account
>  all possible backward compatibility issues, including packaging.

Ah I see, I got the full picture now. Thanks for the explanation.
Well, I think it's not a problem -- if numpy decides
to kick out non-array things, you'll simply package f2py as a
standalone package and that's it. That package, whether it is in numpy
or standalone will include both f2py and g3 f2py, so no problem with
packaging should occur.

Ondrej


More information about the Scipy-dev mailing list