[SciPy-dev] F2PY future

[Pearu Peterson]

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.

Regards,
Pearu