foo at bar.invalid
Sun Aug 23 19:06:48 CEST 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
> 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?
> 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
> 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.
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:
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
More information about the Python-list