[Numpy-discussion] [Numpy-svn] r5198 - trunk/numpy/f2py

[Pearu Peterson]

Stéfan van der Walt wrote:
> Hi Pearu
> 
> 2008/5/20 Pearu Peterson <pearu at cens.ioc.ee>:
>> CC: numpy-discussion because of other reactions on the subject.
>>
>> On Tue, May 20, 2008 1:26 am, Robert Kern wrote:
>>> Is this an important bugfix? If not, can you hold off until 1.1.0 is
>>> released?
>> The patch fixes a long existing and unreported bug in f2py - I think
>> the bug was introduced when Python defined min and max functions.
>> I learned about the bug when reading a manuscript about f2py. Such bugs
>> should not end up in a paper demonstrating f2py inability to process
>> certain
>> features as it would have not been designed to do so. So, I'd consider
>> the bugfix important.
>>
>> On the other hand, the patch does not affect numpy users who do not
>> use f2py, in any way. So, it is not important for numpy users, in general.
> 
> Many f2py users currently get their version via NumPy, I assume.

Yes. There is no other place.

>> Hmm, I also thought that the trunk is open for development, even though
>> r5198 is only fixing a bug (and I do not plan to develop f2py in numpy
>> further, just fix bugs and maintain it). If the release process
>> is going to take for weeks and is locking the trunk, may be the
>> release candidates should live in a separate branch?
> 
> If the patch
> 
> a) Fixes an important bug and
> b) has unit tests to ensure it does what it is supposed to
> 
> then I'd be +1 for applying.  It looks like there are some tests
> included; to which degree do they cover the bugfix, and do we have
> tests to make sure that f2py still functions correctly?

Note that in past f2py was developed using a bit different model
compared to what we require for numpy currently.
The g3 f2py development will be carried out out of numpy tree
but using numpy development model.

Switching numpy.f2py to numpy development model requires substantial
changes, most dramatic one would be to remove f2py;).
A realistic change would require working out a way to test
automatically generated extension modules.
Since this requires existence of C and *Fortran* compilers,
then the test runner must be able to detect the existence of compilers
in order to decide whether to run such tests or not.

So I beg to be flexible with f2py related commits for now. Most changes
are tested by me to ensure that f2py works correctly (as a minimum,
after changing f2py, I always test f2py against scipy).
Some changes may need users feedback because I may
not have access to all commercial Fortran compilers that numpy.distutis
aims at supporting. This development model has not broke f2py in past
as far as I have been concerned. If you will disallow such bug fixes
in future, it would mean that maintaining f2py in numpy will be
practically stopped. I am not sure that we would want that either.

Pearu