DOC: f2py: fix some typos etc

doc/source/f2py/getting-started.rst

@@ -26,7 +26,7 @@ following steps:
 
 Depending on a particular situation, these steps can be carried out
 either by just in one command or step-by-step, some steps can be
-ommited or combined with others.
+omitted or combined with others.
 
 Below I'll describe three typical approaches of using F2PY.
 The following `example Fortran 77 code`__ will be used for
@@ -142,7 +142,7 @@ Python the Fortran subroutine ``FIB`` is accessible via ``fib1.fib``::
   Though the demonstrated way of wrapping Fortran routines to Python
   is very straightforward, it has several drawbacks (see the comments
   above).  These drawbacks are due to the fact that there is no way
-  that F2PY can determine what is the acctual intention of one or the
+  that F2PY can determine what is the actual intention of one or the
   other argument, is it input or output argument, or both, or
   something else. So, F2PY conservatively assumes that all arguments
   are input arguments by default.

doc/source/f2py/python-usage.rst

@@ -144,7 +144,7 @@ and C-contiguous if the order is as follows::
   A[0,0] A[0,1] A[1,0] A[1,1]
 
 To test whether an array is C-contiguous, use ``.iscontiguous()``
-method of Numpy arrays.  To test for Fortran-contiguousness, all
+method of Numpy arrays.  To test for Fortran contiguity, all
 F2PY generated extension modules provide a function
 ``has_column_major_storage(<array>)``. This function is equivalent to
 ``<array>.flags.f_contiguous`` but more efficient.
@@ -155,7 +155,7 @@ functions, assume one or another storage order. F2PY automatically
 ensures that wrapped functions get arguments with proper storage
 order; the corresponding algorithm is designed to make copies of
 arrays only when absolutely necessary. However, when dealing with very
-large multi-dimensional input arrays with sizes close to the size of
+large multidimensional input arrays with sizes close to the size of
 the physical memory in your computer, then a care must be taken to use
 always proper-contiguous and proper type arguments.
 
@@ -269,14 +269,14 @@ routines so that Python functions could be called from Fortran.
      :literal:
 
 The function is included as an argument to the python function call to
-the FORTRAN subroutine eventhough it was NOT in the FORTRAN subroutine argument
+the Fortran subroutine even though it was *not* in the Fortran subroutine argument
 list. The "external" refers to the C function generated by f2py, not the python
 function itself. The python function must be supplied to the C function.
 
 The callback function may also be explicitly set in the module.
 Then it is not necessary to pass the function in the argument list to
-the FORTRAN function. This may be desired if the FORTRAN function calling
-the python callback function is itself called by another FORTRAN function.
+the Fortran function. This may be desired if the Fortran function calling
+the python callback function is itself called by another Fortran function.
 
 .. example::
 
@@ -327,20 +327,20 @@ is provided by an user, and in addition,
 is used, then the following rules are applied when a Fortran or C
 function calls the call-back argument ``gun``:
 
-* If ``p==0`` then ``gun(a_1,...,a_q)`` is called, here
-  ``q=min(m,n)``.
-* If ``n+p<=m`` then ``gun(a_1,...,a_n,e_1,...,e_p)`` is called.
-* If ``p<=m<n+p`` then ``gun(a_1,...,a_q,e_1,...,e_p)`` is called, here
+* If ``p == 0`` then ``gun(a_1, ..., a_q)`` is called, here
+  ``q = min(m, n)``.
+* If ``n + p <= m`` then ``gun(a_1, ..., a_n, e_1, ..., e_p)`` is called.
+* If ``p <= m < n + p`` then ``gun(a_1, ..., a_q, e_1, ..., e_p)`` is called, here
   ``q=m-p``.
-* If ``p>m`` then ``gun(e_1,...,e_m)`` is called.
-* If ``n+p`` is less than the number of required arguments to ``gun``
+* If ``p > m`` then ``gun(e_1, ..., e_m)`` is called.
+* If ``n + p`` is less than the number of required arguments to ``gun``
   then an exception is raised.
 
 The function ``gun`` may return any number of objects as a tuple. Then
 following rules are applied:
 
-* If ``k<l``, then ``y_{k+1},...,y_l`` are ignored.
-* If ``k>l``, then only ``x_1,...,x_l`` are set.
+* If ``k < l``, then ``y_{k + 1}, ..., y_l`` are ignored.
+* If ``k > l``, then only ``x_1, ..., x_l`` are set.
 
 
 
@@ -354,7 +354,7 @@ with the current extension module, but not to other extension modules
 Python, the F2PY wrappers to ``common`` blocks are ``fortran`` type
 objects that have (dynamic) attributes related to data members of
 common blocks. When accessed, these attributes return as Numpy array
-objects (multi-dimensional arrays are Fortran-contiguous) that
+objects (multidimensional arrays are Fortran-contiguous) that
 directly link to data members in common blocks. Data members can be
 changed by direct assignment or by in-place changes to the
 corresponding array objects.

doc/source/f2py/signature-file.rst

@@ -18,7 +18,7 @@ ones;-).
 
 In general, the contents of signature files is case-sensitive.  When
 scanning Fortran codes and writing a signature file, F2PY lowers all
-cases automatically except in multi-line blocks or when ``--no-lower``
+cases automatically except in multiline blocks or when ``--no-lower``
 option is used.
 
 The syntax of signature files is overvied below.
@@ -219,7 +219,7 @@ Other statements:
 
         <implicit map> := <typespec> ( <list of letters or range of letters> )
 
-      Implicit rules are used to deterimine the type specification of
+      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 rule is given by
@@ -260,27 +260,27 @@ Other statements:
       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 explicitely specify the arguments of the
+      statement you can explicitly specify the arguments of the
       corresponding prototype::
 
         extern <return type> FUNC_F(<routine name>,<ROUTINE NAME>)(<callprotoargument>);
 
-  + ``fortranname [<acctual Fortran/C routine name>]``
+  + ``fortranname [<actual Fortran/C routine name>]``
       You can use arbitrary ``<routine name>`` for a given Fortran/C
       function. Then you have to specify
-      ``<acctual Fortran/C routine name>`` with this statement.
+      ``<actual Fortran/C routine name>`` with this statement.
 
       If ``fortranname`` statement is used without
-      ``<acctual Fortran/C routine name>`` then a dummy wrapper is
+      ``<actual Fortran/C routine name>`` then a dummy wrapper is
       generated.
 
   + ``usercode <multi-line block>``
       When used inside ``python module`` block, then 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 in initialization of optional arguments,
-      for example. If ``usercode`` is used twise inside ``python
-      module`` block then the second multi-line block is inserted
+      for example. If ``usercode`` is used twice inside ``python
+      module`` block then the second multiline block is inserted
       after the definition of external routines.
 
       When used inside ``<routine singature>``, then given C code will
@@ -294,7 +294,7 @@ Other statements:
       modules dictionary. For example, for defining additional
       variables etc.
 
-  + ``pymethoddef <multi-line block>``
+  + ``pymethoddef <multiline block>``
       Multiline block will be inserted to the definition of
       module methods ``PyMethodDef``-array. It must be a
       comma-separated list of C arrays (see `Extending and Embedding`__
@@ -350,7 +350,7 @@ The following attributes are used by F2PY:
       "contiguous" Numpy arrays with proper type and size.  Here
       "contiguous" can be either in Fortran or C sense. The latter one
       coincides with the contiguous concept used in Numpy and is
-      effective only if ``intent(c)`` is used. Fortran-contiguousness
+      effective only if ``intent(c)`` is used. Fortran contiguity
       is assumed by default.
 
       Using ``intent(inout)`` is generally not recommended, use
@@ -376,7 +376,7 @@ The following attributes are used by F2PY:
 
       By default, returned multidimensional arrays are
       Fortran-contiguous. If ``intent(c)`` is used, then returned
-      multi-dimensional arrays are C-contiguous.
+      multidimensional arrays are C-contiguous.
 
   + ``hide``
       The argument is removed from the list of required or optional
@@ -393,12 +393,12 @@ The following attributes are used by F2PY:
       as a C scalar argument (recall that Fortran scalar arguments are
       actually C pointer arguments).  In the case of an array
       argument, the wrapper function is assumed to treat
-      multi-dimensional arrays as C-contiguous arrays.
+      multidimensional arrays as C-contiguous arrays.
 
       There is no need to use ``intent(c)`` for one-dimensional
       arrays, no matter if the wrapped function is either a Fortran or
       a C function. This is because the concepts of Fortran- and
-      C-contiguousness overlap in one-dimensional cases.
+      C contiguity overlap in one-dimensional cases.
 
       If ``intent(c)`` is used as an statement but without entity
       declaration list, then F2PY adds ``intent(c)`` attibute to all
@@ -410,7 +410,7 @@ The following attributes are used by F2PY:
 
   + ``cache``
       The argument is treated as a junk of memory. No Fortran nor C
-      contiguousness checks are carried out. Using ``intent(cache)``
+      contiguity checks are carried out. Using ``intent(cache)``
       makes sense only for array arguments, also in connection with
       ``intent(hide)`` or ``optional`` attributes.
 
@@ -564,7 +564,7 @@ F2PY directive has the following form::
 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 Fortran (non-comment) line:
+normal Fortran, non-comment line:
 
   When F2PY finds a line with F2PY directive, the directive is first
   replaced by 5 spaces and then the line is reread.
@@ -581,7 +581,7 @@ C expressions are used in the following parts of signature files:
 * ``<init_expr>`` of 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.
+* ``callstatement`` statement, here also a C multiline block can be used.
 
 A C expression may contain:
 
@@ -629,16 +629,16 @@ is equivalent to ``numpy.arange(n,dtype=float)``.
   F2PY may lower cases also in C expressions when scanning Fortran codes
   (see ``--[no]-lower`` option).
 
-Multi-line blocks
+Multiline 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
+A multiline block starts with ``'''`` (triple single-quotes) and ends
+with ``'''`` in some *strictly* subsequent line.  Multiline blocks can
+be used only within .pyf files. The contents of a multiline 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:
+Currently, multiline blocks can be used in the following constructs:
 
 + as a C expression of the ``callstatement`` statement;
 

doc/source/f2py/usage.rst

@@ -68,7 +68,7 @@ distinguished by the usage of ``-c`` and ``-h`` switches:
      (defined in ``<includefile>``) in F2PY generated wrappers.
 
      This option is deprecated. Use ``usercode`` statement to specify
-     C codelets directly in signature filess
+     C code snippets directly in signature files
 
    ``--[no-]wrap-functions``