Re: Python/Fortran interoperability

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 we

Re: Python/Fortran interoperability

sturlamolden wrote: > On 23 Aug, 20:42, n...@cam.ac.uk wrote: > > > 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.

Re: Python/Fortran interoperability

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 co

Re: Python/Fortran interoperability

James Van Buskirk wrote: > "Richard Maine" wrote in message > news:1j4y84p.v5docbtueccmn%nos...@see.signature... > > > One might plausibly regard this as a kludge, but it is a kludge that is > > part of the Fortran standard and is guaranteed to work with all Fortran > > compilers. I almost sa

Re: Python/Fortran interoperability

"Richard Maine" wrote in message news:1j4y84p.v5docbtueccmn%nos...@see.signature... > There might be a confusion here (and I'm not even sure on whose part) on > a picky but important detail of wording. I have seen multiple people > confused by this one before. In fact, some potential confusion w

Re: Python/Fortran interoperability

On 24 Aug, 21:24, n...@cam.ac.uk wrote: > 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. That's what the code I showed you does. -- http://mail.python.org/mailman/listinfo/python-list

Re: Python/Fortran interoperability

In article , glen herrmannsfeldt wrote: > >< Consider, for example: > > > >< This is not currently allowed and r

Re: Python/Fortran interoperability

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

Re: Python/Fortran interoperability

In comp.lang.fortran n...@cam.ac.uk wrote: (snip) < 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:

Re: Python/Fortran interoperability

On 24 Aug, 20:55, n...@cam.ac.uk wrote: > Precisely.  And 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? > Consider, for example: > >     SUBROUTINE Fred (X) BIND(C) >     CHARACTER*(*) :: X >     END SUBROUTINE Fr

Re: Python/Fortran interoperability

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

Re: Python/Fortran interoperability

sturlamolden wrote: > You also said we can only interop with > length-1 character strings. My kludge was valid Fortran and works with > strings of any length up to some sane limit that you can specify. There might be a confusion here (and I'm not even sure on whose part) on a picky but important

Re: Python/Fortran interoperability

On 24 Aug, 18:20, n...@cam.ac.uk wrote: >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 - You said we have to kludge them up as ar

Re: Python/Fortran interoperability

On Sun, Aug 23, 2009 at 9:21 AM, Stefan Behnel wrote: > 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 >>

Re: Python/Fortran interoperability

sturlamolden wrote: > On 24 Aug, 02:57, nos...@see.signature (Richard Maine) wrote: > > Does anyone use OOP in Fortran anyway? I do - currently for learning (and eventually training) purposes so I don't distribute any of the code. But, the fact that... > Fortran 2003 compilers are not ubiquitou

Re: Python/Fortran interoperability

On 24 Aug, 10:24, n...@cam.ac.uk wrote: > 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

Re: Python/Fortran interoperability

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

Re: Python/Fortran interoperability

sturlamolden wrote: > Does anyone use OOP in Fortran anyway? Presumably not many people yet because... > And Fortran 2003 compilers are not ubiquitous. I'd not only agree, I'd say that was quite a bit understated. Last time I checked, the number of Fortran 2003 compilers available on the most

Re: Python/Fortran interoperability

On 24 Aug, 02:57, nos...@see.signature (Richard Maine) wrote: > Yes, it is no surprise that the C interop stuff fails to address this, > since it isn't in C. Something different/extra would be needed, which is > exactly what Nick said. I'm going to jump out of the middle of this now. > The only re

Re: Python/Fortran interoperability

On 24 Aug, 01:59, sturlamolden wrote: > subroutine foobar(cstr) bind(c, name='foobar') >     use, intrinsic :: iso_c_binding >     type(c_ptr) :: cstr >     character(*), pointer :: fstr >     call c_f_pointer(cptr, fptr) Actually, this does not work, as it is illegal to create a pointer to a ch

Re: Python/Fortran interoperability

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

Re: Python/Fortran interoperability

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,

Re: Python/Fortran interoperability

On 24 Aug, 01:59, sturlamolden wrote: > subroutine foobar(cstr) bind(c, name='foobar') >     use, intrinsic :: iso_c_binding >     type(c_ptr) :: cstr >     character(*), pointer :: fstr >     call c_f_pointer(cptr, fptr) > Which means that you can write a wrapper in Fortran callable from C, tha

Re: Python/Fortran interoperability

On 24 Aug, 00:02, Dennis Lee Bieber wrote: >         That's a C language problem -- since a string in C is just an array > of character. The last FORTRAN dialect (and implementation) I used > passed strings On 24 Aug, 00:02, Dennis Lee Bieber wrote: > values -- FORTRAN strings were typically s

Re: Python/Fortran interoperability

On 23 Aug, 20:42, n...@cam.ac.uk wrote: > 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 woul

Re: Python/Fortran interoperability

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 (

Re: Python/Fortran interoperability

["Followup-To:" header set to comp.lang.fortran.] On 2009-08-23, 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

Re: Python/Fortran interoperability

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 s

Re: Python/Fortran interoperability

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

Re: Python/Fortran interoperability

On Aug 23, 6:35 am, 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