Python/Fortran interoperability

[nmm1 at cam.ac.uk]

In article <slrnh92tp8.qcl.foo at vipunen.hut.fi>, JB  <foo at bar.invalid> wrote:
>["Followup-To:" header set to comp.lang.fortran.]

Sorry - set back again, because you don't provide an Email address,
and there's a significant issue.  Thanks for the response.

>>     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.

No, I mean things like 'Kilroy was here'.  Currently, Fortran's C
interoperability supports only strings of length 1, and you have
to kludge them up as arrays.  That doesn't work very well, especially
for things like function results.

>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:

Thanks.  I will look at that.

>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.

That is precisely what I am investigating.  TR 29113 falls a LONG
way before it gets to any of the OOP data - indeed, you can't even
pass OOP derived types as pure data (without even the functionality)
in its model.  Nor most of what else Python would expect.


Regards,
Nick Maclaren.