In article <slrnh92tp8.qcl....@vipunen.hut.fi>, JB <f...@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. -- http://mail.python.org/mailman/listinfo/python-list
