Signature file

The syntax specification for signature files (.pyf files) is modeled on the Fortran 90/95 language specification. Almost all Fortran 90/95 standard constructs are understood, both in free and fixed format (recall that Fortran 77 is a subset of Fortran 90/95). F2PY introduces some extensions to the Fortran 90/95 language specification that help in the design of the Fortran to Python interface, making it more “Pythonic”.

Signature files may contain arbitrary Fortran code so that any Fortran 90/95 codes can be treated as signature files. F2PY silently ignores Fortran constructs that are irrelevant for creating the interface. However, this also means that syntax errors are not caught by F2PY and will only be caught when the library is built.

In general, the contents of the signature files are case-sensitive. When scanning Fortran codes to generate a signature file, F2PY lowers all cases automatically except in multi-line blocks or when the --no-lower option is used.

The syntax of signature files is presented below.

Python module block

A signature file may contain one (recommended) or more python module blocks. The python module block describes the contents of a Python/C extension module <modulename>module.c that F2PY generates.

Warning

Exception: if <modulename> contains a substring __user__, then the corresponding python module block describes the signatures of call-back functions (see Call-back arguments).

A python module block has the following structure:

python module <modulename>
  [<usercode statement>]...
  [
  interface
    <usercode statement>
    <Fortran block data signatures>
    <Fortran/C routine signatures>
  end [interface]
  ]...
  [
  interface
    module <F90 modulename>
      [<F90 module data type declarations>]
      [<F90 module routine signatures>]
    end [module [<F90 modulename>]]
  end [interface]
  ]...
end [python module [<modulename>]]

Here brackets [] indicate an optional section, dots ... indicate one or more of a previous section. So, []... is to be read as zero or more of a previous section.

Fortran/C routine signatures

The signature of a Fortran routine has the following structure:

[<typespec>] function | subroutine <routine name> \
              [ ( [<arguments>] ) ] [ result ( <entityname> ) ]
  [<argument/variable type declarations>]
  [<argument/variable attribute statements>]
  [<use statements>]
  [<common block statements>]
  [<other statements>]
end [ function | subroutine [<routine name>] ]

From a Fortran routine signature F2PY generates a Python/C extension function that has the following signature:

def <routine name>(<required arguments>[,<optional arguments>]):
     ...
     return <return variables>

The signature of a Fortran block data has the following structure:

block data [ <block data name> ]
  [<variable type declarations>]
  [<variable attribute statements>]
  [<use statements>]
  [<common block statements>]
  [<include statements>]
end [ block data [<block data name>] ]

Type declarations

The definition of the <argument/variable type declaration> part is

<typespec> [ [<attrspec>] :: ] <entitydecl>

where

<typespec> := byte | character [<charselector>]
           | complex [<kindselector>] | real [<kindselector>]
           | double complex | double precision
           | integer [<kindselector>] | logical [<kindselector>]

<charselector> := * <charlen>
               | ( [len=] <len> [ , [kind=] <kind>] )
               | ( kind= <kind> [ , len= <len> ] )
<kindselector> := * <intlen> | ( [kind=] <kind> )

<entitydecl> := <name> [ [ * <charlen> ] [ ( <arrayspec> ) ]
                      | [ ( <arrayspec> ) ] * <charlen> ]
                     | [ / <init_expr> / | = <init_expr> ] \
                       [ , <entitydecl> ]

and

  • <attrspec> is a comma separated list of attributes;

  • <arrayspec> is a comma separated list of dimension bounds;

  • <init_expr> is a C expression;

  • <intlen> may be negative integer for integer type specifications. In such cases integer*<negintlen> represents unsigned C integers;

If an argument has no <argument type declaration>, its type is determined by applying implicit rules to its name.

Statements

Attribute statements

  • The <argument/variable attribute statement> is <argument/variable type declaration> without <typespec>.

  • In addition, in an attribute statement one cannot use other attributes, also <entitydecl> can be only a list of names.

Use statements

  • The definition of the <use statement> part is

    use <modulename> [ , <rename_list> | , ONLY : <only_list> ]

    where

    <rename_list> := <local_name> => <use_name> [ , <rename_list> ]

  • Currently F2PY uses use statement only for linking call-back modules and external arguments (call-back functions), see Call-back arguments.

Common block statements

  • The definition of the <common block statement> part is

    common / <common name> / <shortentitydecl>

    where

    <shortentitydecl> := <name> [ ( <arrayspec> ) ] [ , <shortentitydecl> ]

  • If a python module block contains two or more common blocks with the same name, the variables from the additional declarations are appended. The types of variables in <shortentitydecl> are defined using <argument type declarations>. Note that the corresponding <argument type declarations> may contain array specifications; then these need not be specified in <shortentitydecl>.

Other statements

  • The <other statement> part refers to any other Fortran language constructs that are not described above. F2PY ignores most of them except the following:

    • call statements and function calls of external arguments (more details?);

    • include statements
      include '<filename>'
include "<filename>"

      If a file <filename> does not exist, the include statement is ignored. Otherwise, the file <filename> is included to a signature file. include statements can be used in any part of a signature file, also outside the Fortran/C routine signature blocks.

    • implicit statements
      implicit none
implicit <list of implicit maps>

      where

      <implicit map> := <typespec> ( <list of letters or range of letters> )

      Implicit rules are used to determine the type specification of a variable (from the first-letter of its name) if the variable is not defined using <variable type declaration>. Default implicit rules are given by:

      implicit real (a-h,o-z,$_), integer (i-m)
    • entry statements
      entry <entry name> [([<arguments>])]

      F2PY generates wrappers for all entry names using the signature of the routine block.

      Note

      The entry statement can be used to describe the signature of an arbitrary subroutine or function allowing F2PY to generate a number of wrappers from only one routine block signature. There are few restrictions while doing this: fortranname cannot be used, callstatement and callprotoargument can be used only if they are valid for all entry routines, etc.

F2PY statements

In addition, F2PY introduces the following statements:

threadsafe

Uses a Py_BEGIN_ALLOW_THREADS .. Py_END_ALLOW_THREADS block around the call to Fortran/C function.

callstatement <C-expr|multi-line block>

Replaces the F2PY generated call statement to Fortran/C function with <C-expr|multi-line block>. The wrapped Fortran/C function is available as (*f2py_func).

To raise an exception, set f2py_success = 0 in <C-expr|multi-line block>.

callprotoargument <C-typespecs>

When the callstatement statement is used then F2PY may not generate proper prototypes for Fortran/C functions (because <C-expr> may contain any function calls and F2PY has no way to determine what should be the proper prototype).

With this statement you can explicitly specify the arguments of the corresponding prototype:

extern <return type> FUNC_F(<routine name>,<ROUTINE NAME>)(<callprotoargument>);
fortranname [<actual Fortran/C routine name>]

F2PY allows for the use of an arbitrary <routine name> for a given Fortran/C function. Then this statement is used for the <actual Fortran/C routine name>.

If fortranname statement is used without <actual Fortran/C routine name> then a dummy wrapper is generated.

usercode <multi-line block>

When this is used inside a python module block, the given C code will be inserted to generated C/API source just before wrapper function definitions.

Here you can define arbitrary C functions to be used for the initialization of optional arguments.

For example, if usercode is used twice inside python module block then the second multi-line block is inserted after the definition of the external routines.

When used inside <routine signature>, then the given C code will be inserted into the corresponding wrapper function just after the declaration of variables but before any C statements. So, the usercode follow-up can contain both declarations and C statements.

When used inside the first interface block, then the given C code will be inserted at the end of the initialization function of the extension module. This is how the extension modules dictionary can be modified and has many use-cases; for example, to define additional variables.

pymethoddef <multiline block>

This is a multi-line block which will be inserted into the definition of a module methods PyMethodDef-array. It must be a comma-separated list of C arrays (see Extending and Embedding Python documentation for details). pymethoddef statement can be used only inside python module block.

Attributes

The following attributes are used by F2PY:

optional

The corresponding argument is moved to the end of <optional arguments> list. A default value for an optional argument can be specified via <init_expr>, see the entitydecl definition.

Note

  • The default value must be given as a valid C expression.

  • Whenever <init_expr> is used, optional attribute is set automatically by F2PY.

  • For an optional array argument, all its dimensions must be bounded.

required

The corresponding argument with this attribute considered mandatory. This is the default. required should only be specified if there is a need to disable the automatic optional setting when <init_expr> is used.

If a Python None object is used as a required argument, the argument is treated as optional. That is, in the case of array argument, the memory is allocated. If <init_expr> is given, then the corresponding initialization is carried out.

dimension(<arrayspec>)

The corresponding variable is considered as an array with dimensions given in <arrayspec>.

intent(<intentspec>)

This specifies the “intention” of the corresponding argument. <intentspec> is a comma separated list of the following keys:

  • in

    The corresponding argument is considered to be input-only. This means that the value of the argument is passed to a Fortran/C function and that the function is expected to not change the value of this argument.

  • inout

    The corresponding argument is marked for input/output or as an in situ output argument. intent(inout) arguments can be only “contiguous” NumPy arrays with proper type and size. Here “contiguous” can be either in the Fortran or C sense. The latter coincides with the default contiguous concept used in NumPy and is effective only if intent(c) is used. F2PY assumes Fortran contiguous arguments by default.

    Note

    Using intent(inout) is generally not recommended, use intent(in,out) instead.

    See also the intent(inplace) attribute.

  • inplace

    The corresponding argument is considered to be an input/output or in situ output argument. intent(inplace) arguments must be NumPy arrays of a proper size. If the type of an array is not “proper” or the array is non-contiguous then the array will be modified in-place to fix the type and make it contiguous.

    Note

    Using intent(inplace) is generally not recommended either.

    For example, when slices have been taken from an intent(inplace) argument then after in-place changes, the data pointers for the slices may point to an unallocated memory area.

  • out

    The corresponding argument is considered to be a return variable. It is appended to the <returned variables> list. Using intent(out) sets intent(hide) automatically, unless intent(in) or intent(inout) are specified as well.

    By default, returned multidimensional arrays are Fortran-contiguous. If intent(c) attribute is used, then the returned multidimensional arrays are C-contiguous.

  • hide

    The corresponding argument is removed from the list of required or optional arguments. Typically intent(hide) is used with intent(out) or when <init_expr> completely determines the value of the argument like in the following example:

    integer intent(hide),depend(a) :: n = len(a)
real intent(in),dimension(n) :: a
  • c

    The corresponding argument is treated as a C scalar or C array argument. For the case of a scalar argument, its value is passed to a C function as a C scalar argument (recall that Fortran scalar arguments are actually C pointer arguments). For array arguments, the wrapper function is assumed to treat multidimensional arrays as C-contiguous arrays.

    There is no need to use intent(c) for one-dimensional arrays, irrespective of whether the wrapped function is in Fortran or C. This is because the concepts of Fortran- and C contiguity overlap in one-dimensional cases.

    If intent(c) is used as a statement but without an entity declaration list, then F2PY adds the intent(c) attribute to all arguments.

    Also, when wrapping C functions, one must use intent(c) attribute for <routine name> in order to disable Fortran specific F_FUNC(..,..) macros.

  • cache

    The corresponding argument is treated as junk memory. No Fortran nor C contiguity checks are carried out. Using intent(cache) makes sense only for array arguments, also in conjunction with intent(hide) or optional attributes.

  • copy

    Ensures that the original contents of intent(in) argument is preserved. Typically used with the intent(in,out) attribute. F2PY creates an optional argument overwrite_<argument name> with the default value 0.

  • overwrite

    This indicates that the original contents of the intent(in) argument may be altered by the Fortran/C function. F2PY creates an optional argument overwrite_<argument name> with the default value 1.

  • out=<new name>

    Replaces the returned name with <new name> in the __doc__ string of the wrapper function.

  • callback

    Constructs an external function suitable for calling Python functions from Fortran. intent(callback) must be specified before the corresponding external statement. If the ‘argument’ is not in the argument list then it will be added to Python wrapper but only by initializing an external function.

    Note

    Use intent(callback) in situations where the Fortran/C code assumes that the user implemented a function with a given prototype and linked it to an executable. Don’t use intent(callback) if the function appears in the argument list of a Fortran routine.

    With intent(hide) or optional attributes specified and using a wrapper function without specifying the callback argument in the argument list; then the call-back function is assumed to be found in the namespace of the F2PY generated extension module where it can be set as a module attribute by a user.

  • aux

    Defines an auxiliary C variable in the F2PY generated wrapper function. Useful to save parameter values so that they can be accessed in initialization expressions for other variables.

    Note

    intent(aux) silently implies intent(c).

The following rules apply:

  • If none of intent(in | inout | out | hide) are specified, intent(in) is assumed.

    • intent(in,inout) is intent(in);

    • intent(in,hide) or intent(inout,hide) is intent(hide);

    • intent(out) is intent(out,hide) unless intent(in) or intent(inout) is specified.

  • If intent(copy) or intent(overwrite) is used, then an additional optional argument is introduced with a name overwrite_<argument name> and a default value 0 or 1, respectively.

    • intent(inout,inplace) is intent(inplace);

    • intent(in,inplace) is intent(inplace);

    • intent(hide) disables optional and required.

check([<C-booleanexpr>])

Performs a consistency check on the arguments by evaluating <C-booleanexpr>; if <C-booleanexpr> returns 0, an exception is raised.

Note

If check(..) is not used then F2PY automatically generates a few standard checks (e.g. in a case of an array argument, it checks for the proper shape and size). Use check() to disable checks generated by F2PY.

depend([<names>])

This declares that the corresponding argument depends on the values of variables in the <names> list. For example, <init_expr> may use the values of other arguments. Using information given by depend(..) attributes, F2PY ensures that arguments are initialized in a proper order. If the depend(..) attribute is not used then F2PY determines dependence relations automatically. Use depend() to disable the dependence relations generated by F2PY.

When you edit dependence relations that were initially generated by F2PY, be careful not to break the dependence relations of other relevant variables. Another thing to watch out for is cyclic dependencies. F2PY is able to detect cyclic dependencies when constructing wrappers and it complains if any are found.

allocatable

The corresponding variable is a Fortran 90 allocatable array defined as Fortran 90 module data.

external

The corresponding argument is a function provided by user. The signature of this call-back function can be defined

  • in __user__ module block,

  • or by demonstrative (or real, if the signature file is a real Fortran code) call in the <other statements> block.

For example, F2PY generates from:

external cb_sub, cb_fun
integer n
real a(n),r
call cb_sub(a,n)
r = cb_fun(4)

the following call-back signatures:

subroutine cb_sub(a,n)
    real dimension(n) :: a
    integer optional,check(len(a)>=n),depend(a) :: n=len(a)
end subroutine cb_sub
function cb_fun(e_4_e) result (r)
    integer :: e_4_e
    real :: r
end function cb_fun

The corresponding user-provided Python function are then:

def cb_sub(a,[n]):
    ...
    return
def cb_fun(e_4_e):
    ...
    return r

See also the intent(callback) attribute.

parameter

This indicates that the corresponding variable is a parameter and it must have a fixed value. F2PY replaces all parameter occurrences by their corresponding values.

Extensions

F2PY directives

The F2PY directives allow using F2PY signature file constructs in Fortran 77/90 source codes. With this feature one can (almost) completely skip the intermediate signature file generation and apply F2PY directly to Fortran source codes.

F2PY directives have the following form:

<comment char>f2py ...

where allowed comment characters for fixed and free format Fortran codes are cC*!# and !, respectively. Everything that follows <comment char>f2py is ignored by a compiler but read by F2PY as a normal non-comment Fortran line:

Note

When F2PY finds a line with F2PY directive, the directive is first replaced by 5 spaces and then the line is reread.

For fixed format Fortran codes, <comment char> must be at the first column of a file, of course. For free format Fortran codes, the F2PY directives can appear anywhere in a file.

C expressions

C expressions are used in the following parts of signature files:

  • <init_expr> for variable initialization;

  • <C-booleanexpr> of the check attribute;

  • <arrayspec> of the dimension attribute;

  • callstatement statement, here also a C multi-line block can be used.

A C expression may contain:

  • standard C constructs;

  • functions from math.h and Python.h;

  • variables from the argument list, presumably initialized before according to given dependence relations;

  • the following CPP macros:

    • rank(<name>) Returns the rank of an array <name>.

    • shape(<name>,<n>) Returns the <n>-th dimension of an array <name>.

    • len(<name>) Returns the length of an array <name>.

    • size(<name>) Returns the size of an array <name>.

    • slen(<name>) Returns the length of a string <name>.

For initializing an array <array name>, F2PY generates a loop over all indices and dimensions that executes the following pseudo-statement:

<array name>(_i[0],_i[1],...) = <init_expr>;

where _i[<i>] refers to the <i>-th index value and that runs from 0 to shape(<array name>,<i>)-1.

For example, a function myrange(n) generated from the following signature

subroutine myrange(a,n)
  fortranname        ! myrange is a dummy wrapper
  integer intent(in) :: n
  real*8 intent(c,out),dimension(n),depend(n) :: a = _i[0]
end subroutine myrange

is equivalent to numpy.arange(n,dtype=float).

Warning

F2PY may lower cases also in C expressions when scanning Fortran codes (see --[no]-lower option).

Multi-line blocks

A multi-line block starts with ''' (triple single-quotes) and ends with ''' in some strictly subsequent line. Multi-line blocks can be used only within .pyf files. The contents of a multi-line block can be arbitrary (except that it cannot contain ''') and no transformations (e.g. lowering cases) are applied to it.

Currently, multi-line blocks can be used in the following constructs:

  • as a C expression of the callstatement statement;

  • as a C type specification of the callprotoargument statement;

  • as a C code block of the usercode statement;

  • as a list of C arrays of the pymethoddef statement;

  • as a documentation string.

previous

Using F2PY bindings in Python

next

F2PY and Build Systems