inline(code, arg_names = [ ], local_dict = None, global_dict = None, force = 0, compiler = '', verbose = 0, support_code = None, headers = [ ], customize = None, type_converters = None, auto_downcast = 1, newarr_converter = 0, **kw)Inline C/C++ code within Python scripts.
inline() compiles and executes C/C++ code on the fly. Variables
in the local and global Python scope are also available in the
C/C++ code. Values are passed to the C/C++ code by assignment
much like variables passed are passed into a standard Python
function. Values are returned from the C/C++ code through a
special argument called return_val. Also, the contents of
mutable objects can be changed within the C/C++ code and the
changes remain after the C code exits and returns to Python.
inline has quite a few options as listed below. Also, the keyword
arguments for distutils extension modules are accepted to
specify extra information needed for compiling.
code -- string. A string of valid C++ code. It should not specify a
return statement. Instead it should assign results that
need to be returned to Python in the return_val.
arg_names -- optional. list of strings. A list of Python variable names
that should be transferred from Python into the C/C++
code. It defaults to an empty string.
local_dict -- optional. dictionary. If specified, it is a dictionary
of values that should be used as the local scope for the
C/C++ code. If local_dict is not specified the local
dictionary of the calling function is used.
global_dict -- optional. dictionary. If specified, it is a dictionary
of values that should be used as the global scope for
the C/C++ code. If global_dict is not specified the
global dictionary of the calling function is used.
force -- optional. 0 or 1. default 0. If 1, the C++ code is
compiled every time inline is called. This is really
only useful for debugging, and probably only useful if
your editing support_code a lot.
compiler -- optional. string. The name of compiler to use when
compiling. On windows, it understands 'msvc' and 'gcc'
as well as all the compiler names understood by
distutils. On Unix, it'll only understand the values
understood by distutils. ( I should add 'gcc' though
to this).
On windows, the compiler defaults to the Microsoft C++
compiler. If this isn't available, it looks for mingw32
(the gcc compiler).
On Unix, it'll probably use the same compiler that was
used when compiling Python. Cygwin's behavior should be
similar.
verbose -- optional. 0,1, or 2. defualt 0. Speficies how much
much information is printed during the compile phase
of inlining code. 0 is silent (except on windows with
msvc where it still prints some garbage). 1 informs
you when compiling starts, finishes, and how long it
took. 2 prints out the command lines for the compilation
process and can be useful if your having problems
getting code to work. Its handy for finding the name
of the .cpp file if you need to examine it. verbose has
no affect if the compilation isn't necessary.
support_code -- optional. string. A string of valid C++ code declaring
extra code that might be needed by your compiled
function. This could be declarations of functions,
classes, or structures.
headers -- optional. list of strings. A list of strings specifying
header files to use when compiling the code. The list
might look like ["<vector>","'my_header'"]. Note that
the header strings need to be in a form than can be
pasted at the end of a #include statement in the
C++ code.
customize -- optional. base_info.custom_info object. An alternative
way to specify support_code, headers, etc. needed by
the function see the compiler.base_info module for more
details. (not sure this'll be used much).
type_converters -- optional. list of type converters. These
guys are what convert Python data types to C/C++ data
types. If you'd like to use a different set of type
conversions than the default, specify them here. Look
in the type conversions section of the main
documentation for examples.
auto_downcast -- optional. 0 or 1. default 1. This only affects
functions that have NumPy arrays as input variables.
Setting this to 1 will cause all floating point values
to be cast as float instead of double if all the
Numeric arrays are of type float. If even one of the
arrays has type double or double complex, all
variables maintain there standard types.
Distutils keywords. These are cut and pasted from Greg Ward's
distutils.extension.Extension class for convenience:
sources : [string]
list of source filenames, relative to the distribution root
(where the setup script lives), in Unix form (slash-separated)
for portability. Source files may be C, C++, SWIG (.i),
platform-specific resource files, or whatever else is recognized
by the "build_ext" command as source for a Python extension.
Note: The module_path file is always appended to the front of this
list
include_dirs : [string]
list of directories to search for C/C++ header files (in Unix
form for portability)
define_macros : [(name : string, value : string|None)]
list of macros to define; each macro is defined using a 2-tuple,
where 'value' is either the string to define it to or None to
define it without a particular value (equivalent of "#define
FOO" in source or -DFOO on Unix C compiler command line)
undef_macros : [string]
list of macros to undefine explicitly
library_dirs : [string]
list of directories to search for C/C++ libraries at link time
libraries : [string]
list of library names (not filenames or paths) to link against
runtime_library_dirs : [string]
list of directories to search for C/C++ libraries at run time
(for shared extensions, this is when the extension is loaded)
extra_objects : [string]
list of extra files to link with (eg. object files not implied
by 'sources', static library that must be explicitly specified,
binary resource files, etc.)
extra_compile_args : [string]
any extra platform- and compiler-specific information to use
when compiling the source files in 'sources'. For platforms and
compilers where "command line" makes sense, this is typically a
list of command-line arguments, but for other platforms it could
be anything.
extra_link_args : [string]
any extra platform- and compiler-specific information to use
when linking object files together to create the extension (or
to create a new static Python interpreter). Similar
interpretation as for 'extra_compile_args'.
export_symbols : [string]
list of symbols to be exported from a shared extension. Not
used on all platforms, and not generally necessary for Python
extensions, which typically export exactly one symbol: "init" +
extension_name.
SciPy 0.6.0 API Documentation Generated by Endo, 2007-10-17