Commit ae9a7c07 authored by Stefan Behnel's avatar Stefan Behnel

merge

parents 3c612380 deaa7d0f
......@@ -967,7 +967,7 @@ static int __Pyx_BufFmt_ProcessTypeChunk(__Pyx_BufFmt_Context* ctx) {
if (ctx->fmt_offset != offset) {
PyErr_Format(PyExc_ValueError,
"Buffer dtype mismatch; next field is at offset %"PY_FORMAT_SIZE_T"d "
"but %"PY_FORMAT_SIZE_T"d expected", ctx->fmt_offset, offset);
"but %"PY_FORMAT_SIZE_T"d expected", (Py_ssize_t)ctx->fmt_offset, (Py_ssize_t)offset);
return -1;
}
......@@ -1168,7 +1168,7 @@ static CYTHON_INLINE int __Pyx_GetBufferAndValidate(Py_buffer* buf, PyObject* ob
"Item size of buffer (%"PY_FORMAT_SIZE_T"d byte%s) does not match size of '%s' (%"PY_FORMAT_SIZE_T"d byte%s)",
buf->itemsize, (buf->itemsize > 1) ? "s" : "",
dtype->name,
dtype->size, (dtype->size > 1) ? "s" : "");
(Py_ssize_t)dtype->size, (dtype->size > 1) ? "s" : "");
goto fail;
}
if (buf->suboffsets == NULL) buf->suboffsets = __Pyx_minusones;
......
......@@ -1374,7 +1374,7 @@ class CCodeWriter(object):
return self.globalstate.lookup_filename(filename)
def put_declare_refcount_context(self):
self.putln('__Pyx_RefNannyDeclarations;')
self.putln('__Pyx_RefNannyDeclarations')
def put_setup_refcount_context(self, name):
self.putln('__Pyx_RefNannySetupContext("%s");' % name)
......
......@@ -7776,7 +7776,7 @@ static PyObject *__Pyx_FindPy2Metaclass(PyObject *bases) {
#if PY_MAJOR_VERSION < 3
if (PyTuple_Check(bases) && PyTuple_GET_SIZE(bases) > 0) {
PyObject *base = PyTuple_GET_ITEM(bases, 0);
metaclass = PyObject_GetAttrString(base, "__class__");
metaclass = PyObject_GetAttrString(base, (char *)"__class__");
if (!metaclass) {
PyErr_Clear();
metaclass = (PyObject*) Py_TYPE(base);
......@@ -7854,7 +7854,7 @@ PyObject *__Pyx_Py3MetaclassPrepare(PyObject *metaclass, PyObject *bases, PyObje
PyObject *ns;
PyObject *str;
prep = PyObject_GetAttrString(metaclass, "__prepare__");
prep = PyObject_GetAttrString(metaclass, (char *)"__prepare__");
if (!prep) {
if (!PyErr_ExceptionMatches(PyExc_AttributeError))
return NULL;
......@@ -8560,7 +8560,7 @@ static PyObject *__Pyx_Generator_Throw(PyObject *self, PyObject *args, CYTHON_UN
PyObject *tb = NULL;
PyObject *val = NULL;
if (!PyArg_UnpackTuple(args, "throw", 1, 3, &typ, &val, &tb))
if (!PyArg_UnpackTuple(args, (char *)"throw", 1, 3, &typ, &val, &tb))
return NULL;
__Pyx_Raise(typ, val, tb);
return __Pyx_Generator_SendEx(generator, NULL);
......
......@@ -2758,7 +2758,7 @@ proto="""
} __Pyx_RefNannyAPIStruct;
static __Pyx_RefNannyAPIStruct *__Pyx_RefNanny = NULL;
static __Pyx_RefNannyAPIStruct *__Pyx_RefNannyImportAPI(const char *modname); /*proto*/
#define __Pyx_RefNannyDeclarations void *__pyx_refnanny = NULL
#define __Pyx_RefNannyDeclarations void *__pyx_refnanny = NULL;
#define __Pyx_RefNannySetupContext(name) \
__pyx_refnanny = __Pyx_RefNanny->SetupContext((name), __LINE__, __FILE__)
#define __Pyx_RefNannyFinishContext() \
......
......@@ -1623,20 +1623,24 @@ class FuncDefNode(StatNode, BlockNode):
info = self.local_scope.arg_entries[1].cname
# Python 3.0 betas have a bug in memoryview which makes it call
# getbuffer with a NULL parameter. For now we work around this;
# the following line should be removed when this bug is fixed.
code.putln("if (%s == NULL) return 0;" % info)
# the following block should be removed when this bug is fixed.
code.putln("if (%s != NULL) {" % info)
code.putln("%s->obj = Py_None; __Pyx_INCREF(Py_None);" % info)
code.put_giveref("%s->obj" % info) # Do not refnanny object within structs
code.putln("}")
def getbuffer_error_cleanup(self, code):
info = self.local_scope.arg_entries[1].cname
code.putln("if (%s != NULL && %s->obj != NULL) {"
% (info, info))
code.put_gotref("%s->obj" % info)
code.putln("__Pyx_DECREF(%s->obj); %s->obj = NULL;" %
(info, info))
code.putln("__Pyx_DECREF(%s->obj); %s->obj = NULL;"
% (info, info))
code.putln("}")
def getbuffer_normal_cleanup(self, code):
info = self.local_scope.arg_entries[1].cname
code.putln("if (%s->obj == Py_None) {" % info)
code.putln("if (%s != NULL && %s->obj == Py_None) {" % (info, info))
code.put_gotref("Py_None")
code.putln("__Pyx_DECREF(Py_None); %s->obj = NULL;" % info)
code.putln("}")
......
......@@ -2794,7 +2794,7 @@ def p_code(s, level=None):
repr(s.sy), repr(s.systring)))
return body
COMPILER_DIRECTIVE_COMMENT_RE = re.compile(r"^#\s*cython:\s*((\w|[.])+\s*=.*)$")
COMPILER_DIRECTIVE_COMMENT_RE = re.compile(r"^#\s*cython\s*:\s*((\w|[.])+\s*=.*)$")
def p_compiler_directive_comments(s):
result = {}
......
......@@ -190,6 +190,9 @@ cdef extern from "numpy/arrayobject.h":
# requirements, and does not yet fullfill the PEP.
# In particular strided access is always provided regardless
# of flags
if info == NULL: return
cdef int copy_shape, i, ndim
cdef int endian_detector = 1
cdef bint little_endian = ((<char*>&endian_detector)[0] != 0)
......
......@@ -2,138 +2,248 @@
.. _compilation:
***********
=============
Compilation
***********
=============
* Cython code, unlike Python, must be compiled.
* This happens in two stages:
Cython code, unlike Python, must be compiled. This happens in two stages:
* A ``.pyx`` file is compiles by Cython to a ``.c`` file.
* The ``.c`` file is compiled by a C comiler to a ``.so`` file (or a ``.pyd`` file on Windows)
* A ``.pyx`` file is compiles by Cython to a ``.c`` file.
* The following sub-sections describe several ways to build your extension modules.
* The ``.c`` file is compiled by a C compiler to a ``.so`` file (or a
``.pyd`` file on Windows)
.. note:: The ``-a`` option
* Using the Cython compiler with the ``-a`` option will produce a really nice HTML file of the Cython generated ``.c`` code.
* Double clicking on the highlighted sections will expand the code to reveal what Cython has actually generated for you.
* This is very useful for understanding, optimizing or debugging your module.
The following sub-sections describe several ways to build your
extension modules, and how to pass directives to the Cython compiler.
=====================
From the Command Line
=====================
Compiling from the command line
===============================
* Run the Cython compiler command with your options and list of ``.pyx`` files to generate::
Run the Cython compiler command with your options and list of ``.pyx``
files to generate. For example::
$ cython -a yourmod.pyx
* This creates a ``yourmod.c`` file. (and the -a switch produces a generated html file)
* Compiling your ``.c`` files will vary depending on your operating system.
This creates a ``yourmod.c`` file, and the -a switch produces a
generated html file. Pass the ``-h`` flag for a complete list of
supported flags.
* Python documentation for writing extension modules should have some details for your system.
* Here we give an example on a Linux system::
Compiling your ``.c`` files will vary depending on your operating
system. Python documentation for writing extension modules should
have some details for your system. Here we give an example on a Linux
system::
$ gcc -shared -pthread -fPIC -fwrapv -O2 -Wall -fno-strict-aliasing -I/usr/include/python2.5 -o yourmod.so yourmod.c
* ``gcc`` will need to have paths to your included header files and paths to libraries you need to link with.
* A ``yourmod.so`` file is now in the same directory.
* Your module, ``yourmod`` is available for you to import as you normally would.
[``gcc`` will need to have paths to your included header files and
paths to libraries you need to link with]
A ``yourmod.so`` file is now in the same directory and your module,
``yourmod``, is available for you to import as you normally would.
=========
Distutils
=========
Compiling with ``distutils``
============================
* Ensure Distutils is installed in your system.
* The following assumes a Cython file to be compiled called *hello.pyx*.
* Create a ``setup.py`` script::
First, make sure that ``distutils`` package is installed in your
system. The following assumes a Cython file to be compiled called
*hello.pyx*. Now, create a ``setup.py`` script::
from distutils.core import setup
from distutils.extension import Extension
from Cython.Distutils import build_ext
ext_modules = [Extension("hello", ["hello.pyx"])]
ext_modules = [Extension("spam", ["spam.pyx"]),
Extension("ham", ["ham.pyx"])]
# You can add directives for each extension too
# by attaching the `pyrex_directives`
for e in ext modules:
e.pyrex_directives = {"boundscheck": False}
setup(
name = ’Hello world app’,
cmdclass = {’build_ext’: build_ext},
name = "My hello app",
cmdclass = {"build_ext": build_ext},
ext_modules = ext_modules
)
* Run the command ``python setup.py build_ext --inplace`` in your system's command shell.
* Your done.. import your new extension module into your python shell or script as normal.
=====
SCons
=====
Run the command ``python setup.py build_ext --inplace`` in your
system's command shell and you are done. Import your new extension
module into your python shell or script as normal.
to be completed...
Cython provides utility code to automatically generate lists of
Extension objects from ```.pyx`` files, so one can write::
=========
Pyximport
=========
from distutils.core import setup
from Cython.Build import cythonize
* For generating Cython code right in your pure python modulce::
setup(
name = "My hello app",
ext_modules = cythonize("*.pyx"),
)
>>> import pyximport; pyximport.install()
>>> import helloworld
Hello World
to compile all ``.pyx`` files in a given directory.
The ``cythonize`` command also allows for multi-threaded compilation and
dependency resolution.
* Use for simple Cython builds only.
Compiling with ``pyximport``
=============================
* No extra C libraries.
* No special build setup needed.
For generating Cython code right in your pure python module just type::
* Also has experimental compilation support for normal Python modules.
>>> import pyximport; pyximport.install()
>>> import helloworld
Hello World
* Allows you to automatically run Cython on every ``.pyx`` and ``.py`` module that Python imports.
This allows you to automatically run Cython on every ``.pyx`` that
Python is trying to import. You should use this for simple Cython
builds only where no extra C libraries and no special building setup
is needed.
* This includes the standard library and installed packages.
* In the case that Cython fails to compile a Python module, *pyximport* will fall back to loading the source modules instead.
In the case that Cython fails to compile a Python module, *pyximport*
will fall back to loading the source modules instead.
* The ``.py`` import mechanism is installed like this::
It is also possible to compile new ``.py`` modules that are being
imported (including the standard library and installed packages). For
using this feature, just tell that to ``pyximport``::
>>> pyximport.install(pyimport = True)
.. note:: Authors
Paul Prescod, Stefan Behnal
====
Sage
====
The Sage notebook allows transparently editing and
compiling Cython code simply by typing %cython at
the top of a cell and evaluate it. Variables and func-
tions defined in a Cython cell imported into the run-
ning session.
.. todo:: Provide a link to Sage docs
Compiling with ``cython.inline``
=============================
One can also compile Cython in a fashion similar to SciPy's ``weave.inline``.
For example::
>>> import cython
>>> def f(a):
... ret = cython.inline("return a+b", b=3)
...
Unbound variables are automatically pulled from the surrounding local
and global scopes, and the result of the compilation is cached for
efficient re-use.
Compiling with Sage
===================
The Sage notebook allows transparently editing and compiling Cython
code simply by typing ``%cython`` at the top of a cell and evaluate
it. Variables and functions defined in a Cython cell are imported into the
running session. Please check `Sage documentation
<http://www.sagemath.org/doc/>`_ for details.
You can tailor the behavior of the Cython compiler by specifying the
directives below.
====================
Compiler directives
====================
Compiler directives are instructions which affect the behavior of
Cython code. Here is the list of currently supported directives:
``boundscheck`` (True / False)
If set to False, Cython is free to assume that indexing operations
([]-operator) in the code will not cause any IndexErrors to be
raised. Currently this is only made use of for buffers, lists and
tuples, but could be affected other types in the future. Conditions
which would normally trigger an IndexError may instead cause
segfaults or data corruption if this is set to False.
Default is True.
``wraparound`` (True / False)
In Python arrays can be indexed relative to the end. For example
A[-1] indexes the last value of a list. In C negative indexing is
not supported. If set to False, Cython will neither check for nor
correctly handle negative indices, possibly causing segfaults or
data corruption.
Default is True.
``nonecheck`` (True / False)
If set to False, Cython is free to assume that native field
accesses on variables typed as an extension type, or buffer
accesses on a buffer variable, never occurs when the variable is
set to ``None``. Otherwise a check is inserted and the
appropriate exception is raised. This is off by default for
performance reasons. Default is False.
``embedsignature`` (True / False)
If set to True, Cython will embed a textual copy of the call
signature in the docstring of all Python visible functions and
classes. Tools like IPython and epydoc can thus display the
signature, which cannot otherwise be retrieved after
compilation. Default is False.
``cdivision`` (True / False)
If set to False, Cython will adjust the remainder and quotient
operators C types to match those of Python ints (which differ when
the operands have opposite signs) and raise a
``ZeroDivisionError`` when the right operand is 0. This has up to
a 35% speed penalty. If set to True, no checks are performed. See
`CEP 516 <http://wiki.cython.org/enhancements/division>`_. Default
is False.
``cdivision_warnings`` (True / False)
If set to True, Cython will emit a runtime warning whenever
division is performed with negative operands. See `CEP 516
<http://wiki.cython.org/enhancements/division>`_. Default is
False.
``always_allow_keywords`` (True / False)
Avoid the ``METH_NOARGS`` and ``METH_O`` when constructing
functions/methods which take zero or one arguments. Has no effect
on special methods and functions with more than one argument. The
``METH_NOARGS`` and ``METH_O`` signatures provide faster
calling conventions but disallow the use of keywords.
``profile`` (True / False)
Add hooks for Python profilers into the compiled C code. Default
is False.
``infer_types`` (True / False)
Infer types of untyped variables in function bodies. Default is
None, indicating that on safe (semantically-unchanging) inferences
are allowed.
How to set directives
---------------------
Globally
:::::::::
One can set compiler directives through a special header comment at the top of the file, like this::
#!python
#cython: boundscheck=False
The comment must appear before any code (but can appear after other
comments or whitespace).
One can also pass a directive on the command line by using the -X switch::
$ cython -X boundscheck=True ...
Directives passed on the command line will override directives set in
header comments.
Locally
::::::::
For local blocks, you need to cimport the special builtin ``cython``
module::
#!python
cimport cython
Then you can use the directives either as decorators or in a with
statement, like this::
#!python
@cython.boundscheck(False) # turn off boundscheck for this function
def f():
...
with cython.boundscheck(True): # turn it temporarily on again for this block
...
.. Warning:: These two methods of setting directives are **not**
affected by overriding the directive on the command-line using the
-X option.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment