Re: Python/Fortran interoperability

[nmm1]

In article ,
sturlamolden   wrote:
>
>You also made this claim regarding Fortran's C interop with strings:
>
>"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."
>
>This obviosuly proves you wrong:

Er, no, it doesn't.  I suggest that you read what I said more
carefully - and the Fortran standard.  As I said, you can kludge
them up, and that is precisely one such kludge - but, as I also
said, it doesn't work very well.

However, I shall take your answer as a "yes, I want to do that".



Regards,
Nick Maclaren.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python/Fortran interoperability

[nmm1]

In article <1032c78d-d4dd-41c0-a877-b85ca000d...@g31g2000yqc.googlegroups.com>,
sturlamolden   wrote:
>On 23 Aug, 12:35, n...@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. =A0Any suggestions as t=
>o
>> other ways that I could survey such people (Usenet is no longer as
>> ubiquitous as it used to be) would be welcomed.
>
>I think you will find that 99.9% of Python and Fortran programmers are
>scientists and engineers that also use NumPy and f2py. Go to scipy.org
>and ask your question on the numpy mailing list.
>
>Regards,
>Sturla Molden
>
>
>


Thanks.  I had forgotten they had a mailing list.

Nick.
-- 
http://mail.python.org/mailman/listinfo/python-list

Python/Fortran interoperability

[nmm1]

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?

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.

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.


Regards,
Nick Maclaren.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python/Fortran interoperability

[nmm1]

In article ,
glen herrmannsfeldt   wrote:
> 
>< Consider, for example:
> 
> 
> 
>< This is not currently allowed and raises all sorts of 'interesting'
>< implementation and portability questions.  For example, I defy anyone
>< to write Fred portably in C :-)
>
>You mean, how does FRED know the length?  It seems to me the
>usual question for Fortran assumed size arrays.  Assuming that
>FRED can tell from the passed string, it seems fine to me.
>If not, it is a problem.  

Precisely.  And the whole point of my question is how many people
WANT to do it, from the point of view of extending BIND(C).

>< Even when Fred has an explicit length, there are some problematic
>< cases, which could catch out programmers in one language that don't
>< know the other fairly well.  But those are much less of a problem
>< than the common need for assumed length CHARACTER arguments.
>
>Maybe Fortran programmers who started in Fortran 66 will not
>have so much problem with this.  The usual way would be to
>pass the length, as with assumed size arrays.  I believe terminating
>strings with unusual (likely not null) characters was also done.

Yeah.  But there are a decreasing number of us left :-)

Prefix length strings were also used.


Regards,
Nick Maclaren.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python/Fortran interoperability

[nmm1]

In article <7abee4bb-b18a-4680-817b-7e76aed40...@c2g2000yqi.googlegroups.com>,
sturlamolden   wrote:
>
>> Precisely. =A0And the kludge does NOT work under all circumstances,
>> which is why I said that it doesn't work very well.
>
>Do you have an example?

I gave you one.  Also see below.

>> Consider, for example:
>>
>> =A0 =A0 SUBROUTINE Fred (X) BIND(C)
>> =A0 =A0 CHARACTER*(*) :: X
>> =A0 =A0 END SUBROUTINE Fred
>
>Obviously that is not allowed, because C does not know anything about
>Fortran strings. How should a C compiler pass the correct data
>structure to Fred?

Precisely.  The reason I asked that question is that it would be
possible to extend the standard to make it possible in a portable
fashion.

You might also like to consider the converse problem: how to write
a Fortran function that takes a C string of arbitrary length and
uses it.


Regards,
Nick Maclaren.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python/Fortran interoperability

[nmm1]

In article <1j4y84p.v5docbtueccmn%nos...@see.signature>,
Richard Maine  wrote:
>
>Only character strings of length 1 are interoperable, as the term
>"interoperable" is defined in the Fortran standard. However, that does
>not mean that only character strings of length 1 will work with C. The
>distinction might be picky, but it is important.

Precisely.  And the kludge does NOT work under all circumstances,
which is why I said that it doesn't work very well.

Consider, for example:

SUBROUTINE Fred (X) BIND(C)
CHARACTER*(*) :: X
END SUBROUTINE Fred

CHARACTER(LEN=100) :: string
CALL Fred(string(40:60))
CALL Fred(string(5:50))

This is not currently allowed and raises all sorts of 'interesting'
implementation and portability questions.  For example, I defy anyone
to write Fred portably in C :-)

It gets really hairy if you have functions that have assumed length
results, but those are obsolescent.

Even when Fred has an explicit length, there are some problematic
cases, which could catch out programmers in one language that don't
know the other fairly well.  But those are much less of a problem
than the common need for assumed length CHARACTER arguments.


Regards,
Nick Maclaren.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python/Fortran interoperability

[nmm1]

In article <5134d9f1-0e23-4e05-a817-bf0cc9e85...@w6g2000yqw.googlegroups.com>,
sturlamolden   wrote:
>On 24 Aug, 02:26, nos...@see.signature (Richard Maine) wrote:
>
>> You missed the word "OOP", which seemed like the whole point. Not that
>> the particular word is used in the Fortran standard, but it isn't hard
>> to guess that he means a derived type that uses some of the OOP
>> features. Inheritance, polymorphism, and type-bound procedure (aka
>> methods in some other languages) come to mind.
>
>But C is not OOP. The ISO C bindings in Fortran are not ISO C++
>bindings. This is for a reason: C++ does not have a standard ABI like
>ISO C.

Nor does C.  Almost everything that most people believe about C is
wrong, because C is not well-defined at any level, so there are
many twisty little C languages, all different.

Richard is perfectly correct that my point was OOP.  C interoperability
does not apply to any derived type with type-bound procedures, which
include finalizers.  Note that this ALSO forbids them from being
passed as data, even if the other language never uses the OOP features
of the type.


Regards,
Nick Maclaren.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python/Fortran interoperability

[nmm1]

In article , JB   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.
-- 
http://mail.python.org/mailman/listinfo/python-list