incorrect constructors if type is a varname about f90wrap HOT 10 CLOSED

type is a reserved word in Python, hence the remapping to type_bn (bn stands for "bad name"), which is the same transformation that the standard f2py would apply. It appears that this is not being done completely consistently, however. I'll look into it.

from f90wrap.

I fully agree that using type as a name while it is already used for something else even in fortran is a poor choice. I guess that most of the problems f90wrap will encounter with the code i try to use will come from non-rigorous subroutines. To see this on the bright side, it will give you leads to achieve a more robust wrapper ;)

Yann

Le 4 nov. 2015 à 16:07, James Kermode [email protected] a écrit :

type is a reserved word in Python, hence the remapping to type_bn (bn stands for "bad name"), which is the same transformation that the standard f2py would apply. It appears that this is not being done completely consistently, however. I'll look into it.

—
Reply to this email directly or view it on GitHub #30 (comment).

from f90wrap.

Should now be fixed. Let me know if you have further problems.

from f90wrap.

It seems to work and I thank you for your responsiveness.
I am now faced with another issue : the fortran code I try to use is
full of "pointer" variables like this :

real,dimension(:,:),pointer :: x

From what i read about f2py, pointer data is not supported. Could your
wrapper do something about that, or at least is there any way around
this "pointer" property of the variable ?
For now, subroutines with pointer variables are ignored without warning
and the module class ends up with only "pass" in the user-friendly .py
generated file.

Thanks again for your time an dedication to your project : )

Yann

Le mar. 17 nov. 2015 à 16:01, James Kermode [email protected]
a écrit :

Should now be fixed. Let me know if you have further problems.

—
Reply to this email directly or view it on GitHub.

from f90wrap.

I don't remember where the limitation on pointer arugments comes wrong. I will try to have a look at a simple example soon- I'm reopening this issue to keep track.

from f90wrap.

Here is a minimal example producing an empty python wrapper and an f2py3 error at the Building Modules step:

module module_calcul
contains
subroutine evaluer_valeur(x)
real,dimension(:,:),pointer :: x
    x = 2
    return
end subroutine evaluer_valeur
end module module_calcul

from f90wrap.

I'm sorry to re-open this case but it seems that the fix for "type" as a member name inside a type is not 100% working. With the minimal example provided at the beginning of this issue, the python commands

import maxwell
a = maxwell.module_structure.Face()

results in : AttributeError: module '_maxwell' has no attribute 'f90wrap_face_initialise'.

from f90wrap.

Got it.
I propose you to replace line 714 of file f90wrapgen.py
if localvar in getattr(el, "uses", []) or localvar in extra_uses:
by
if localvar in getattr(el, "uses", []) or localvar in extra_uses or localvar == "type":

I know you have a list of bad names, so of course it would be better to modify with something like
... localvar not in bad_names_list
and this should do the trick.

from f90wrap.

Hi : )

Rather than checking for uses, bad names, or who knows what we are forgetting this time, I think it is easier to just append "_f90wrap" to all type members. I updated my pull request accordingly.

(and proposed a bug fix on another subject as well)

from f90wrap.

Agreed - I merged your updated pull request, thanks.

Since there is already an F90WrapperGenerator.prefix attribute, so I removed the hard-coded "_f90wrap" suffix and switched it to use a prefix instead (commit 140dc916665a7). Let me know of any further problems.

from f90wrap.