Updated date, example function documentation and python links

3 files changed, 74 insertions, 72 deletions

diff --git a/numpy/doc/swig/numpy_swig.html b/numpy/doc/swig/numpy_swig.html
index eadfc3f3a..90706ac84 100644
--- a/numpy/doc/swig/numpy_swig.html
+++ b/numpy/doc/swig/numpy_swig.html
@@ -5,7 +5,7 @@
 <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
 <title>numpy.i: a SWIG Interface File for NumPy</title>
 <meta name="author" content="Bill Spotz" />
-<meta name="date" content="4 April, 2007" />
+<meta name="date" content="13 April, 2007" />
 <style type="text/css">
 
 /*
@@ -302,7 +302,7 @@ ul.auto-toc {
 <tr class="field"><th class="docinfo-name">Institution:</th><td class="field-body">Sandia National Laboratories</td>
 </tr>
 <tr><th class="docinfo-name">Date:</th>
-<td>4 April, 2007</td></tr>
+<td>13 April, 2007</td></tr>
 </tbody>
 </table>
 <div class="contents topic">
@@ -363,6 +363,7 @@ string):</p>
 <pre class="literal-block">
 def rms(seq):
     &quot;&quot;&quot;
+    rms: return the root mean square of a sequence
     rms(numpy.ndarray) -&gt; double
     rms(list) -&gt; double
     rms(tuple) -&gt; double
@@ -453,19 +454,19 @@ above will produce wrapper code that looks something like:</p>
 <p>The typemaps from <tt class="docutils literal"><span class="pre">numpy.i</span></tt> are responsible for the following lines
 of code: 12--20, 25 and 30.  Line 10 parses the input to the <tt class="docutils literal"><span class="pre">rms</span></tt>
 function.  From the format string <tt class="docutils literal"><span class="pre">&quot;O:rms&quot;</span></tt>, we can see that the
-argument list is expected to be a single python object (specified by
-the <tt class="docutils literal"><span class="pre">O</span></tt> before the colon) and whose pointer is stored in <tt class="docutils literal"><span class="pre">obj0</span></tt>.
-A number of functions, supplied by <tt class="docutils literal"><span class="pre">numpy.i</span></tt>, are called to make and
-check the (possible) conversion from a generic python object to a
-<a class="reference" href="http://numpy.scipy.org">NumPy</a> array.  These functions are explained in the section <a class="reference" href="#helper-functions">Helper
-Functions</a>, but hopefully their names are self-explanatory.  At line
-12 we use <tt class="docutils literal"><span class="pre">obj0</span></tt> to construct a <a class="reference" href="http://numpy.scipy.org">NumPy</a> array.  At line 17, we
-check the validity of the result: that it is non-null and that it has
-a single dimension of arbitrary length.  Once these states are
-verified, we extract the data buffer and length in lines 19 and 20 so
-that we can call the underlying C function at line 22.  Line 25
-performs memory management for the case where we have created a new
-array that is no longer needed.</p>
+argument list is expected to be a single <a class="reference" href="http://www.python.org">python</a> object (specified
+by the <tt class="docutils literal"><span class="pre">O</span></tt> before the colon) and whose pointer is stored in
+<tt class="docutils literal"><span class="pre">obj0</span></tt>.  A number of functions, supplied by <tt class="docutils literal"><span class="pre">numpy.i</span></tt>, are called
+to make and check the (possible) conversion from a generic <a class="reference" href="http://www.python.org">python</a>
+object to a <a class="reference" href="http://numpy.scipy.org">NumPy</a> array.  These functions are explained in the
+section <a class="reference" href="#helper-functions">Helper Functions</a>, but hopefully their names are
+self-explanatory.  At line 12 we use <tt class="docutils literal"><span class="pre">obj0</span></tt> to construct a <a class="reference" href="http://numpy.scipy.org">NumPy</a>
+array.  At line 17, we check the validity of the result: that it is
+non-null and that it has a single dimension of arbitrary length.  Once
+these states are verified, we extract the data buffer and length in
+lines 19 and 20 so that we can call the underlying C function at line
+22.  Line 25 performs memory management for the case where we have
+created a new array that is no longer needed.</p>
 <p>This code has a significant amount of error handling.  Note the
 <tt class="docutils literal"><span class="pre">SWIG_fail</span></tt> is a macro for <tt class="docutils literal"><span class="pre">goto</span> <span class="pre">fail</span></tt>, refering to the label at
 line 28.  If the user provides the wrong number of arguments, this
@@ -623,12 +624,12 @@ arrays in, they simply get returned.  The argout signatures are</p>
 </blockquote>
 <p>These are typically used in situations where in C/C++, you would
 allocate a(n) array(s) on the heap, and call the function to fill the
-array(s) values.  In python, the arrays are allocated for you and
+array(s) values.  In <a class="reference" href="http://www.python.org">python</a>, the arrays are allocated for you and
 returned as new array objects.</p>
 <p>Note that we support <tt class="docutils literal"><span class="pre">DATA_TYPE*</span></tt> argout typemaps in 1D, but not 2D
 or 3D.  This because of a quirk with the <a class="reference" href="http://www.swig.org">SWIG</a> typemap syntax and
 cannot be avoided.  Note that for these types of 1D typemaps, the
-python function will take a single argument representing <tt class="docutils literal"><span class="pre">DIM1</span></tt>.</p>
+<a class="reference" href="http://www.python.org">python</a> function will take a single argument representing <tt class="docutils literal"><span class="pre">DIM1</span></tt>.</p>
 </div>
 <div class="section">
 <h2><a class="toc-backref" href="#id7" id="output-arrays" name="output-arrays">Output Arrays</a></h2>
@@ -696,9 +697,9 @@ typedef struct {double real, imag;} npy_cdouble;
 type <tt class="docutils literal"><span class="pre">Py_complex</span></tt>, <tt class="docutils literal"><span class="pre">npy_cfloat</span></tt> and <tt class="docutils literal"><span class="pre">npy_cdouble</span></tt>.  However, it
 seemed unlikely that there would be any independent (non-<a class="reference" href="http://www.python.org">python</a>,
 non-<a class="reference" href="http://numpy.scipy.org">NumPy</a>) application code that people would be using <a class="reference" href="http://www.swig.org">SWIG</a> to
-generate a python interface to, that also used these definitions for
-complex types.  More likely, these application codes will define their
-own complex types, or in the case of C++, use <tt class="docutils literal"><span class="pre">std::complex</span></tt>.
+generate a <a class="reference" href="http://www.python.org">python</a> interface to, that also used these definitions
+for complex types.  More likely, these application codes will define
+their own complex types, or in the case of C++, use <tt class="docutils literal"><span class="pre">std::complex</span></tt>.
 Assuming these data structures are compatible with <a class="reference" href="http://www.python.org">python</a> and
 <a class="reference" href="http://numpy.scipy.org">NumPy</a> complex types, <tt class="docutils literal"><span class="pre">%numpy_typemap</span></tt> expansions as above (with
 the user's complex type substituted for the first argument) should
@@ -750,7 +751,7 @@ order.  Equivalent to <tt class="docutils literal"><span class="pre">(PyArray_IS
 <p>Return type: <tt class="docutils literal"><span class="pre">char*</span></tt></p>
 <p>Arguments:</p>
 <ul class="simple">
-<li><tt class="docutils literal"><span class="pre">PyObject*</span> <span class="pre">py_obj</span></tt>, a general python object.</li>
+<li><tt class="docutils literal"><span class="pre">PyObject*</span> <span class="pre">py_obj</span></tt>, a general <a class="reference" href="http://www.python.org">python</a> object.</li>
 </ul>
 <p>Return a string describing the type of <tt class="docutils literal"><span class="pre">py_obj</span></tt>.</p>
 </blockquote>
@@ -782,19 +783,19 @@ equivalent to <tt class="docutils literal"><span class="pre">PyArray_EquivTypenu
 <p>Return type: <tt class="docutils literal"><span class="pre">PyArrayObject*</span></tt></p>
 <p>Arguments:</p>
 <ul class="simple">
-<li><tt class="docutils literal"><span class="pre">PyObject*</span> <span class="pre">input</span></tt>, a general python object.</li>
+<li><tt class="docutils literal"><span class="pre">PyObject*</span> <span class="pre">input</span></tt>, a general <a class="reference" href="http://www.python.org">python</a> object.</li>
 <li><tt class="docutils literal"><span class="pre">int</span> <span class="pre">typecode</span></tt>, the desired <a class="reference" href="http://numpy.scipy.org">NumPy</a> typecode.</li>
 </ul>
 <p>Cast <tt class="docutils literal"><span class="pre">input</span></tt> to a <tt class="docutils literal"><span class="pre">PyArrayObject*</span></tt> if legal, and ensure that
 it is of type <tt class="docutils literal"><span class="pre">typecode</span></tt>.  If <tt class="docutils literal"><span class="pre">input</span></tt> cannot be cast, or the
-<tt class="docutils literal"><span class="pre">typecode</span></tt> is wrong, set a python error and return <tt class="docutils literal"><span class="pre">NULL</span></tt>.</p>
+<tt class="docutils literal"><span class="pre">typecode</span></tt> is wrong, set a <a class="reference" href="http://www.python.org">python</a> error and return <tt class="docutils literal"><span class="pre">NULL</span></tt>.</p>
 </blockquote>
 <p><strong>obj_to_array_allow_conversion()</strong></p>
 <blockquote>
 <p>Return type: <tt class="docutils literal"><span class="pre">PyArrayObject*</span></tt></p>
 <p>Arguments:</p>
 <ul class="simple">
-<li><tt class="docutils literal"><span class="pre">PyObject*</span> <span class="pre">input</span></tt>, a general python object.</li>
+<li><tt class="docutils literal"><span class="pre">PyObject*</span> <span class="pre">input</span></tt>, a general <a class="reference" href="http://www.python.org">python</a> object.</li>
 <li><tt class="docutils literal"><span class="pre">int</span> <span class="pre">typecode</span></tt>, the desired <a class="reference" href="http://numpy.scipy.org">NumPy</a> typecode of the resulting
 array.</li>
 <li><tt class="docutils literal"><span class="pre">int*</span> <span class="pre">is_new_object</span></tt>, returns a value of 0 if no conversion
@@ -802,7 +803,7 @@ performed, else 1.</li>
 </ul>
 <p>Convert <tt class="docutils literal"><span class="pre">input</span></tt> to a <a class="reference" href="http://numpy.scipy.org">NumPy</a> array with the given <tt class="docutils literal"><span class="pre">typecode</span></tt>.
 On success, return a valid <tt class="docutils literal"><span class="pre">PyArrayObject*</span></tt> with the correct
-type.  On failure, the python error string will be set and the
+type.  On failure, the <a class="reference" href="http://www.python.org">python</a> error string will be set and the
 routine returns <tt class="docutils literal"><span class="pre">NULL</span></tt>.</p>
 </blockquote>
 <p><strong>make_contiguous()</strong></p>
@@ -826,7 +827,7 @@ as a new object and return the pointer.</p>
 <p>Return type: <tt class="docutils literal"><span class="pre">PyArrayObject*</span></tt></p>
 <p>Arguments:</p>
 <ul class="simple">
-<li><tt class="docutils literal"><span class="pre">PyObject*</span> <span class="pre">input</span></tt>, a general python object.</li>
+<li><tt class="docutils literal"><span class="pre">PyObject*</span> <span class="pre">input</span></tt>, a general <a class="reference" href="http://www.python.org">python</a> object.</li>
 <li><tt class="docutils literal"><span class="pre">int</span> <span class="pre">typecode</span></tt>, the desired <a class="reference" href="http://numpy.scipy.org">NumPy</a> typecode of the resulting
 array.</li>
 <li><tt class="docutils literal"><span class="pre">int*</span> <span class="pre">is_new_object</span></tt>, returns a value of 0 if no conversion
@@ -845,7 +846,7 @@ flag will be set.</p>
 <li><tt class="docutils literal"><span class="pre">PyArrayObject*</span> <span class="pre">ary</span></tt>, a <a class="reference" href="http://numpy.scipy.org">NumPy</a> array.</li>
 </ul>
 <p>Test whether <tt class="docutils literal"><span class="pre">ary</span></tt> is contiguous.  If so, return 1.  Otherwise,
-set a python error and return 0.</p>
+set a <a class="reference" href="http://www.python.org">python</a> error and return 0.</p>
 </blockquote>
 <p><strong>require_native()</strong></p>
 <blockquote>
@@ -855,8 +856,8 @@ set a python error and return 0.</p>
 <li><tt class="docutils literal"><span class="pre">PyArray_Object*</span> <span class="pre">ary</span></tt>, a <a class="reference" href="http://numpy.scipy.org">NumPy</a> array.</li>
 </ul>
 <p>Require that <tt class="docutils literal"><span class="pre">ary</span></tt> is not byte-swapped.  If the array is not
-byte-swapped, return 1.  Otherwise, set a python error and return
-0.</p>
+byte-swapped, return 1.  Otherwise, set a <a class="reference" href="http://www.python.org">python</a> error and
+return 0.</p>
 </blockquote>
 <p><strong>require_dimensions()</strong></p>
 <blockquote>
@@ -868,7 +869,7 @@ byte-swapped, return 1.  Otherwise, set a python error and return
 </ul>
 <p>Require <tt class="docutils literal"><span class="pre">ary</span></tt> to have a specified number of dimensions.  If the
 array has the specified number of dimensions, return 1.
-Otherwise, set a python error and return 0.</p>
+Otherwise, set a <a class="reference" href="http://www.python.org">python</a> error and return 0.</p>
 </blockquote>
 <p><strong>require_dimensions_n()</strong></p>
 <blockquote>
@@ -882,8 +883,8 @@ acceptable numbers of dimensions.</li>
 </ul>
 <p>Require <tt class="docutils literal"><span class="pre">ary</span></tt> to have one of a list of specified number of
 dimensions.  If the array has one of the specified number of
-dimensions, return 1.  Otherwise, set the python error string and
-return 0.</p>
+dimensions, return 1.  Otherwise, set the <a class="reference" href="http://www.python.org">python</a> error string
+and return 0.</p>
 </blockquote>
 <p><strong>require_size()</strong></p>
 <blockquote>
@@ -896,8 +897,8 @@ each dimension.</li>
 <li><tt class="docutils literal"><span class="pre">int</span> <span class="pre">n</span></tt>, the length of <tt class="docutils literal"><span class="pre">size</span></tt>.</li>
 </ul>
 <p>Require <tt class="docutils literal"><span class="pre">ary</span></tt> to have a specified shape.  If the array has the
-specified shape, return 1.  Otherwise, set the python error string
-and return 0.</p>
+specified shape, return 1.  Otherwise, set the <a class="reference" href="http://www.python.org">python</a> error
+string and return 0.</p>
 </blockquote>
 </blockquote>
 </div>
@@ -912,7 +913,7 @@ a simple <tt class="docutils literal"><span class="pre">%include</span> <span cl
 <pre class="literal-block">
 double dot(int len, double* vec1, double* vec2);
 </pre>
-<p>The python interface that we want is:</p>
+<p>The <a class="reference" href="http://www.python.org">python</a> interface that we want is:</p>
 <pre class="literal-block">
 def dot(vec1, vec2):
     &quot;&quot;&quot;
@@ -922,7 +923,7 @@ def dot(vec1, vec2):
 <p>The problem here is that there is one dimension argument and two array
 arguments, and our typemaps are set up for dimensions that apply to a
 single array (in fact, <a class="reference" href="http://www.swig.org">SWIG</a> does not provide a mechanism for
-associating <tt class="docutils literal"><span class="pre">len</span></tt> with <tt class="docutils literal"><span class="pre">vec2</span></tt> that takes two python input
+associating <tt class="docutils literal"><span class="pre">len</span></tt> with <tt class="docutils literal"><span class="pre">vec2</span></tt> that takes two <a class="reference" href="http://www.python.org">python</a> input
 arguments).  The recommended solution is the following:</p>
 <pre class="literal-block">
 %apply (int DIM1, double* IN_ARRAY1) {(int len1, double* vec1),
@@ -1052,7 +1053,7 @@ possible.</p>
 </div>
 <div class="footer">
 <hr class="footer" />
-Generated on: 2007-04-13 20:37 UTC.
+Generated on: 2007-04-13 20:43 UTC.
 Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
 
 </div>
diff --git a/numpy/doc/swig/numpy_swig.pdf b/numpy/doc/swig/numpy_swig.pdf
index 6e18049c3..aadcc9fe4 100644
--- a/numpy/doc/swig/numpy_swig.pdf
+++ b/numpy/doc/swig/numpy_swig.pdf
diff --git a/numpy/doc/swig/numpy_swig.txt b/numpy/doc/swig/numpy_swig.txt
index 19d9045a9..d00ad6ff5 100644
--- a/numpy/doc/swig/numpy_swig.txt
+++ b/numpy/doc/swig/numpy_swig.txt
@@ -4,7 +4,7 @@ numpy.i: a SWIG Interface File for NumPy
 
 :Author:      Bill Spotz
 :Institution: Sandia National Laboratories
-:Date:        4 April, 2007
+:Date:        13 April, 2007
 
 .. contents::
 
@@ -41,6 +41,7 @@ string)::
 
     def rms(seq):
         """
+	rms: return the root mean square of a sequence
         rms(numpy.ndarray) -> double
         rms(list) -> double
         rms(tuple) -> double
@@ -134,19 +135,19 @@ above will produce wrapper code that looks something like::
 The typemaps from ``numpy.i`` are responsible for the following lines
 of code: 12--20, 25 and 30.  Line 10 parses the input to the ``rms``
 function.  From the format string ``"O:rms"``, we can see that the
-argument list is expected to be a single python object (specified by
-the ``O`` before the colon) and whose pointer is stored in ``obj0``.
-A number of functions, supplied by ``numpy.i``, are called to make and
-check the (possible) conversion from a generic python object to a
-`NumPy`_ array.  These functions are explained in the section `Helper
-Functions`_, but hopefully their names are self-explanatory.  At line
-12 we use ``obj0`` to construct a `NumPy`_ array.  At line 17, we
-check the validity of the result: that it is non-null and that it has
-a single dimension of arbitrary length.  Once these states are
-verified, we extract the data buffer and length in lines 19 and 20 so
-that we can call the underlying C function at line 22.  Line 25
-performs memory management for the case where we have created a new
-array that is no longer needed.
+argument list is expected to be a single `python`_ object (specified
+by the ``O`` before the colon) and whose pointer is stored in
+``obj0``.  A number of functions, supplied by ``numpy.i``, are called
+to make and check the (possible) conversion from a generic `python`_
+object to a `NumPy`_ array.  These functions are explained in the
+section `Helper Functions`_, but hopefully their names are
+self-explanatory.  At line 12 we use ``obj0`` to construct a `NumPy`_
+array.  At line 17, we check the validity of the result: that it is
+non-null and that it has a single dimension of arbitrary length.  Once
+these states are verified, we extract the data buffer and length in
+lines 19 and 20 so that we can call the underlying C function at line
+22.  Line 25 performs memory management for the case where we have
+created a new array that is no longer needed.
 
 This code has a significant amount of error handling.  Note the
 ``SWIG_fail`` is a macro for ``goto fail``, refering to the label at
@@ -305,13 +306,13 @@ arrays in, they simply get returned.  The argout signatures are
 
 These are typically used in situations where in C/C++, you would
 allocate a(n) array(s) on the heap, and call the function to fill the
-array(s) values.  In python, the arrays are allocated for you and
+array(s) values.  In `python`_, the arrays are allocated for you and
 returned as new array objects.
 
 Note that we support ``DATA_TYPE*`` argout typemaps in 1D, but not 2D
 or 3D.  This because of a quirk with the `SWIG`_ typemap syntax and
 cannot be avoided.  Note that for these types of 1D typemaps, the
-python function will take a single argument representing ``DIM1``.
+`python`_ function will take a single argument representing ``DIM1``.
 
 Output Arrays
 -------------
@@ -382,9 +383,9 @@ which would have provided automatic type conversions for arrays of
 type ``Py_complex``, ``npy_cfloat`` and ``npy_cdouble``.  However, it
 seemed unlikely that there would be any independent (non-`python`_,
 non-`NumPy`_) application code that people would be using `SWIG`_ to
-generate a python interface to, that also used these definitions for
-complex types.  More likely, these application codes will define their
-own complex types, or in the case of C++, use ``std::complex``.
+generate a `python`_ interface to, that also used these definitions
+for complex types.  More likely, these application codes will define
+their own complex types, or in the case of C++, use ``std::complex``.
 Assuming these data structures are compatible with `python`_ and
 `NumPy`_ complex types, ``%numpy_typemap`` expansions as above (with
 the user's complex type substituted for the first argument) should
@@ -442,7 +443,7 @@ Routines
 
     Arguments:
 
-    * ``PyObject* py_obj``, a general python object.
+    * ``PyObject* py_obj``, a general `python`_ object.
 
     Return a string describing the type of ``py_obj``.
 
@@ -480,13 +481,13 @@ Routines
 
     Arguments:
 
-    * ``PyObject* input``, a general python object.
+    * ``PyObject* input``, a general `python`_ object.
 
     * ``int typecode``, the desired `NumPy`_ typecode.
 
     Cast ``input`` to a ``PyArrayObject*`` if legal, and ensure that
     it is of type ``typecode``.  If ``input`` cannot be cast, or the
-    ``typecode`` is wrong, set a python error and return ``NULL``.
+    ``typecode`` is wrong, set a `python`_ error and return ``NULL``.
 
 
   **obj_to_array_allow_conversion()**
@@ -495,7 +496,7 @@ Routines
 
     Arguments:
 
-    * ``PyObject* input``, a general python object.
+    * ``PyObject* input``, a general `python`_ object.
 
     * ``int typecode``, the desired `NumPy`_ typecode of the resulting
       array.
@@ -505,7 +506,7 @@ Routines
 
     Convert ``input`` to a `NumPy`_ array with the given ``typecode``.
     On success, return a valid ``PyArrayObject*`` with the correct
-    type.  On failure, the python error string will be set and the
+    type.  On failure, the `python`_ error string will be set and the
     routine returns ``NULL``.
 
 
@@ -536,7 +537,7 @@ Routines
 
     Arguments:
 
-    * ``PyObject* input``, a general python object.
+    * ``PyObject* input``, a general `python`_ object.
 
     * ``int typecode``, the desired `NumPy`_ typecode of the resulting
       array.
@@ -559,7 +560,7 @@ Routines
     * ``PyArrayObject* ary``, a `NumPy`_ array.
 
     Test whether ``ary`` is contiguous.  If so, return 1.  Otherwise,
-    set a python error and return 0.
+    set a `python`_ error and return 0.
 
 
   **require_native()**
@@ -571,8 +572,8 @@ Routines
     * ``PyArray_Object* ary``, a `NumPy`_ array.
 
     Require that ``ary`` is not byte-swapped.  If the array is not
-    byte-swapped, return 1.  Otherwise, set a python error and return
-    0.
+    byte-swapped, return 1.  Otherwise, set a `python`_ error and
+    return 0.
 
   **require_dimensions()**
 
@@ -586,7 +587,7 @@ Routines
 
     Require ``ary`` to have a specified number of dimensions.  If the
     array has the specified number of dimensions, return 1.
-    Otherwise, set a python error and return 0.
+    Otherwise, set a `python`_ error and return 0.
 
 
   **require_dimensions_n()**
@@ -604,8 +605,8 @@ Routines
 
     Require ``ary`` to have one of a list of specified number of
     dimensions.  If the array has one of the specified number of
-    dimensions, return 1.  Otherwise, set the python error string and
-    return 0.
+    dimensions, return 1.  Otherwise, set the `python`_ error string
+    and return 0.
 
 
   **require_size()**
@@ -622,8 +623,8 @@ Routines
     * ``int n``, the length of ``size``.
 
     Require ``ary`` to have a specified shape.  If the array has the
-    specified shape, return 1.  Otherwise, set the python error string
-    and return 0.
+    specified shape, return 1.  Otherwise, set the `python`_ error
+    string and return 0.
 
 
 Beyond the Provided Typemaps
@@ -639,7 +640,7 @@ Consider a reasonable prototype for a dot product function::
 
     double dot(int len, double* vec1, double* vec2);
 
-The python interface that we want is::
+The `python`_ interface that we want is::
 
     def dot(vec1, vec2):
         """
@@ -649,7 +650,7 @@ The python interface that we want is::
 The problem here is that there is one dimension argument and two array
 arguments, and our typemaps are set up for dimensions that apply to a
 single array (in fact, `SWIG`_ does not provide a mechanism for
-associating ``len`` with ``vec2`` that takes two python input
+associating ``len`` with ``vec2`` that takes two `python`_ input
 arguments).  The recommended solution is the following::
 
     %apply (int DIM1, double* IN_ARRAY1) {(int len1, double* vec1),