Python/Fortran interoperability

JB foo at bar.invalid
Sun Aug 23 13:06:48 EDT 2009


["Followup-To:" header set to comp.lang.fortran.]
On 2009-08-23, nmm1 at cam.ac.uk <nmm1 at cam.ac.uk> wrote:
>
> I am interested in surveying people who want to interoperate between
> Fortran and Python to find out what they would like to be able to do
> more conveniently, especially with regard to types not supported for C
> interoperability by the current Fortran standard.  Any suggestions as to
> other ways that I could survey such people (Usenet is no longer as
> ubiquitous as it used to be) would be welcomed.
>
> My Email address is real, so direct messages will be received.
>
> Specifically, I should like to know the answers to the following
> questions:
>
>     1) Do you want to use character strings of arbitrary length?

As in, a signed C int (that most Fortran implementations use to keep
track of string lengths) may not be sufficient? No, I'm not
particularly interested in that.

>     2) Do you want to use Python classes with list members, where the
> length of the list is not necessarily fixed for all instances of the
> class?  Or, equivalently, Fortran derived types containing allocatable
> or pointer arrays?

Yes.

>     2) Do you want to use Fortran derived types or Python classes that
> contain type-bound procedures (including finalizers)?  Please answer
> "yes" whether or nor you would like to call those type-bound procedures
> from the other language.

In python I use it all the time, haven't used any F2003 OOP features
yet.  

>     4) Do you want to call functions where the called language allocates
> or deallocates arrays/lists/strings for use by the calling language?
> Note that this is specifically Fortran->Python and Python->Fortran.

Yes. 


Generally speaking, f2py today is not that bad, though it's getting
long in the tooth. There is a project called fwrap that aims to create
an improved python/Fortran bridge:

http://conference.scipy.org/static/wiki/smith_fwrap.pdf

This project uses ISO_C_BINDING, and I think that this is the correct
approach rather than trying to keep up with whatever ABI's all those
Fortran compilers use. So from the Fortran side of the fence, I
suppose the path forward would be to improve on the C binding
functionality (this would also of course benefit other language
bindings than just python). Whether TR 29113 is the right path forward
or not I have no strong opinion on. Specifically what's needed is some
way to portably access the array descriptor data, and maybe also how
to access the OOP functionality in a standardized way. The experience
with C++ ABI's suggests that this might not be as straightforward as
it sounds.


-- 
JB



More information about the Python-list mailing list