scipy tutorial - Baustatik-Info-Server

from weave import inline
>>> a = ’a longer string’
>>> support_code = """
... PyObject* length(Py::String a)
... {
... int l = a.length();
... return Py::new_reference_to(Py::Int(l));
... }
... """
>>> inline("return_val = length(a);",[’a’],
... support_code = support_code)
15
SciPy Reference Guide, Release 0.8.dev
customize is a left over from a previous way of specifying compiler options. It is a custom_info object that can
specify quite a bit of information about how a file is compiled. These info objects are the standard way of defining
compile information for type conversion classes. However, I don’t think they are as handy here, especially since we’ve
exposed all the keyword arguments that distutils can handle. Between these keywords, and the support_code
option, I think customize may be obsolete. We’ll see if anyone cares to use it. If not, it’ll get axed in the next
version.
The type_factories variable is important to people who want to customize the way arguments are converted
from Python to C. We’ll talk about this in the next chapter xx of this document when we discuss type conversions.
auto_downcast handles one of the big type conversion issues that is common when using NumPy arrays in conjunction
with Python scalar values. If you have an array of single precision values and multiply that array by a Python
scalar, the result is upcast to a double precision array because the scalar value is double precision. This is not usually
the desired behavior because it can double your memory usage. auto_downcast goes some distance towards
changing the casting precedence of arrays and scalars. If your only using single precision arrays, it will automatically
downcast all scalar values from double to single precision when they are passed into the C++ code. This is the default
behavior. If you want all values to keep there default type, set auto_downcast to 0.
Returning Values
Python variables in the local and global scope transfer seemlessly from Python into the C++ snippets. And, if inline
were to completely live up to its name, any modifications to variables in the C++ code would be reflected in the Python
variables when control was passed back to Python. For example, the desired behavior would be something like:
# THIS DOES NOT WORK
>>> a = 1
>>> weave.inline("a++;",[’a’])
>>> a
2
Instead you get:
>>> a = 1
>>> weave.inline("a++;",[’a’])
>>> a
1
Variables are passed into C++ as if you are calling a Python function. Python’s calling convention is sometimes called
“pass by assignment”. This means its as if a c_a = a assignment is made right before inline call is made and the
c_a variable is used within the C++ code. Thus, any changes made to c_a are not reflected in Python’s a variable.
Things do get a little more confusing, however, when looking at variables with mutable types. Changes made in C++
to the contents of mutable types are reflected in the Python variables.
1.12. Weave 101