[f2py] Resend: Threading and Wrapping C-code with f2py

[Travis Oliphant]

Let me preface this message by just saying how much I like f2py.  I have
continually been impressed with this piece of code.  It has simplified one
of my goals of getting lots of Numerical functionality into Python
considerably.

Great job Pearu.

> > 1.  Threading:
> >
> > Would it be possible to add to f2py a directive indicating that a wrapped
> > module is thread-safe.  This directive would instruct f2py to insert
> >
> > Py_BEGIN_ALLOW_THREADS
> >   function call
> > Py_END_ALLOW_THREADS
> >
>
> Sure. (This feature has been requested also earlier)
> Easiest way would be to introduce a command line flag,
> eg. --with-threads. Though the users may want only some routines to be
> thread safe. So, a new directive needs to be introduced anyway.
>

I think that mixing non-thread safe and thread-safe routines could be a
farily regular exercise and so that having a per-module directive would be
useful.

>
> > 2. Calling C-libraries.
> >
> > For simple C-libraries it is possible to use f2py.  However, this seems to
> > only work if all of the arguments to the C-function are pointers.
> >
> > Is there any way to add to f2py a directive that instructs f2py to build a
> > module that is intended to call a C-library, so that scalar arguments are
> > passed directly by value in the function call.
>
> How badly is this feature required? How often it would be used?
> I am working with the 3rd edition of f2py where a bit clearer structure of
> f2py internals is planned.
> I am thinking of a program - c2py - that would, similarly to f2py,
> generate wrappers for C codes. I guess it would not be a big project as
> most of the f2py code could be reused.

Well, it would be nice to be able to wrap simple c codes using the f2py
interface file structure.  The current need arises from trying to
autogenerate c-code and fortran-code interfaces to the atlas blas and
lapack libraries for SciPy.

For those who don't know, ATLAS is a project to create auto-tuned blas and
limited lapack libraries for different architecture.  Part of that work
is the creation of c-based blas libraries.  These are similar to the
Fortran libraries except for scalar-type calling convention, the addition
of an ordering flag to tell the code which order the arrays are in
(row- or column-) ordering, and the different handling of the info.

We have a generic *.pyf file that generates a fortran and C interface file
for use with f2py.  Though the row-ordering issue would be solved by
calling the C-blas codes. The current implementation of f2py cannot
actually call the C-blas codes due to the non-pointer handling of scalar
types.

I made some crude changes to f2py locally so that an interface
subroutine/function which is preceeded by f2pyC calls the code using
C-style conventions.  This has allowed using f2py to create a working
interface to the C-based blas libraries.

It's not very pretty but it seems to work.  A c2py program might be a
better idea (it's actually a simple change) to the arg_rules list of
dictionaries in rules.py).

>
>
> > 3. Using a different Python name.
> >
> > This has been discussed on this list before.  But, it would be really useful
> > to be able to rename the Python-determined function.  There are many ways to
> > do this but it would be useful if some meaningful directive were added to the
> > CrackFortran code.
>
> Yes. It is often requested feature. Any suggestions about what directives
> could be used in pyf files?
> THough this feature should go into f2py3e (unless it is easy to implement
> for f2py2e - I have not tried yet)
>

I'm glad it's on the radar screen.


I've been away from using f2py for a while and I forgot how much I like to
use it...

-Travis