[f2py] Resend: Threading and Wrapping C-code with f2py
Wed, 29 Aug 2001 12:48:04 -0600 (MDT)
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
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
> > 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
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