Stefan Behnel | 6 Aug 09:08 2013

[Cython] Fwd: [cython] no_gc_clear implementation (disable tp_clear) + doc and tests (#248)


this pull request looks good to me. Any objections to merging it in?


-------- Original-Message --------
please consider merging these changes. I am sure there is a lot to improve
especially wrt. the docs, but I think this is very usable already.

Apart from the no_gc_clear decorator, this also changes the tp_clear
implementation to use Py_CLEAR to set the references to NULL.

Greetings, Torsten
You can merge this Pull Request by running:

  git pull master

Or you can view, comment on it, or merge it online at:

-- Commit Summary --

  * Change tp_clear generation to clear to NULL.
  * Add decorator  <at> gc_no_clear to disable tp_clear slot.

-- File Changes --

    M Cython/Compiler/ (12)
(Continue reading)

Lisandro Dalcin | 5 Aug 21:00 2013

[Cython] Git tag for 0.19.1?

I cannot find the tag 0.19.1 in the repository? Did you forget to push it?


Lisandro Dalcin
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
3000 Santa Fe, Argentina
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169
Stefan Behnel | 3 Aug 18:24 2013

[Cython] PEP 442: safe object finalisation


CPython 3.4 will have a new way to handle object finalisation.

I think we should switch the current deallocation code to make use of it.
That should fix the problem we currently have with user provided
__dealloc__() code that touches Python objects. It would be Py3.4+
specific, though.

Wolfgang | 25 Jul 17:46 2013

[Cython] Windows Debug build improvement


thank you.
But I don't use for the build.

I use cython as a code generator and include the generated files into a
Visual Studio project. But that's no problem, VS has the ability of custom
build steps.
A simple build with distutils is not possible.
Because I use not the VC version used to build the python executable.
The external library has other dependencies.

Also the project uses over 15 other Python libraries and none of them is
available as a Windows debug version with "_d" extension.

Basically this is a flaw in Python itself. For a Linux build of Python
there is the "Py_DEBUG" flag used as indicator, set during config. For Windows
this is not explicit, it is set if "_DEBUG" is set. And I think this implicit
setting is not good. (because this flag is widely used elsewhere)
But I have to workaround it, even if Python 3.4 or later changes it
I still use Python 2.7.

Boost Python does this in its configuration, see documentation:
--- copied from boost documentation

On unix-variant platforms, the debugging versions of Python's data structures
will only be used if the symbol Py_DEBUG is defined. On many windows
compilers, when extension modules are built with the preprocessor symbol
_DEBUG, Python defaults to force linking with a special debugging version of
the Python DLL. Since that symbol is very commonly used even when Python is
(Continue reading)

Yury V. Zaytsev | 22 Jul 16:45 2013

[Cython] [Fwd: [cython-users] Conditional compilation of Cython code / preprocessor / external conditions]


After a bit more research, I found two options that I initially

1) (Apparently undocumented) provisions to provide external attributes
in cython_compile_time_env

2) Generation of the PXI file from the external build system

I don't like (2) very much, so I've got an idea to extend (1) with the
ability to pass -D options to cython compiler, like:

    cython -DHAVE_LIBFOO=1

Will any such pull request be accepted?


Sincerely yours,
Yury V. Zaytsev

-------- Forwarded Message --------
From: Yury V. Zaytsev <yury@...>
Reply-to: cython-users@...
To: cython-users@...
Subject: [cython-users] Conditional compilation of Cython code /
preprocessor / external conditions
Date: Mon, 22 Jul 2013 16:17:58 +0200

Hi folks,
(Continue reading)

Wolfgang | 18 Jul 15:24 2013

[Cython] Windows Debug build improvement


I tried to submit a improvement for the Windows build but the tracker is not
accessible without a login.

On Windows if someone does a Debug build of an extension the flag _DEBUG is
set and so the Python Interpreter sets Py_DEBUG and for all extension modules
"_d" is appended to load the debug version of a module.
This is not really practical because then all modules and the Python
Interpreter must be build in Debug mode. For some modules this is even not
possible for Windows. :-(

To do a debug build for a Cython generated extension with a normal Python
Interpreter (none Debug) I have to patch the pyconfig.h file and undef _DEBUG
or I must patch the generated c file from Cython to undef _DEBUG before
pyconfig.h or Python.h is included. (and enable it afterwards)

Is it possible to add a flag to Cython to generate code that does this ?

Something like described in Boost.Python:

It is enough to have a new Preprocessor Flag, if set, then surround the
Python.h inclusion with a disabled _DEBUG.

My workarround is to disable it before pyconfig.h (Python.h) include:

#ifdef _DEBUG
#undef _DEBUG
#define _RESTORE
(Continue reading)

Lev Givon | 18 Jul 23:07 2013

[Cython] typo in buffers.pxd?

The PyBuffer_FillInfo() function definition in the latest revision of
Cython/Includes/cpython/buffer.pxd appears to be missing a parameter. Shouldn't
it be something like the following?

int PyBuffer_FillInfo(Py_buffer *view, object obj, void *buf,
                      Py_ssize_t len, int readonly,
                      int flags) except -1


Lev Givon
Hannes Röst | 17 Jul 14:45 2013

[Cython] Cython compiler directives: c_string_encoding

Dear mailing  list

I am trying to compile a program with Cython using the compiler directives and
I am running into some trouble. Specifically, I am trying to port a Cython 0.18
program to Cython 0.19 and due to changes how char * and Python str are
handled, I need to set the c_string_encoding directive. Unfortunately, this
fails for my project and also in the following testcase when I try to do it

cimport cython
cdef class TestClass:
    def foo(self):
        with cython.c_string_encoding("ascii"):

If I replace the directive with "with cython.boundscheck(True):" the program
compiles fine. Also adding "#cython: c_string_encoding=ascii" as the first line
of the file works fine. However, adding a decorator
' <at> cython.c_string_encoding("ascii")' to foo also crashes the compiler. Finally,
compiling with "-X c_string_encoding=ascii" also works.

I was following the documentation provided here . The error message that
I get is attached at the end. Did I do something wrong or can somebody point me
in the right direction?

Best regards

Hannes Roest

(Continue reading)

Yury V. Zaytsev | 17 Jul 13:59 2013

[Cython] Bug: C++ strings defined in a PXD file are empty


Please find a minimal reproducer attached:

    In [1]: import pxdbug
    This should show 'bad value': 
    This should show 'good value': good value

Is this a real bug or I'm missing something fundamental about the PXD
files? If it's the former, shall I create an issue on the Trac or



Sincerely yours,
Yury V. Zaytsev

from libcpp.string cimport string

cdef string STR_BAD = "bad value"

# distutils: language = c++

from libcpp.string cimport string

(Continue reading)

Yury V. Zaytsev | 15 Jul 17:03 2013

[Cython] Difference between Cython / Python isinstance() vs. NumPy scalars, whose bug is this?


I've debugged my problem with passing NumPy scalars via Cython into C++
down to the fact that inside Cython code `isinstance(x, float)` returns
True on floating point NumPy scalars, but `isinstance(x, (int, long))`
returns False on integer NumPy scalars.

However, when I run the same code from within Python, both checks work
just fine. So is this a genuine bug in Cython, or, rather, NumPy is
doing some black magic behind the scenes, that prevents Cython-compiled
modules from working correctly?

Here is a minimal reproducer for your convenience (tested with Cython
0.19.1, Python 2.7.1 and NumPy 1.7.1):

# bt.pyx

def foo(x):
    if isinstance(x, (int, long)):
        print("I'm an integer number")
    elif isinstance(x, float):
        print("I'm a floating point number")
        print("I don't know who I am")

# IPython transcript

In [1]: import numpy as np

In [2]: import bt
(Continue reading)

Stefan Behnel | 14 Jul 13:19 2013

[Cython] next releases


I'm preparing another bug-fix point release and very conservatively merged
over a few change sets into 0.19.x that seemed to be safe fixes. Please
take a look and also propose or pick more changes if you feel that I left
something out.

Regarding the next master release, the only larger new feature I can see is
Vitja's updated type inference engine. I think it should go in, but it
needs some testing against "real" code (both Python and Cython, I guess).

The exttype noclear and nogc options should also go in, preferably with
some more enhancements that make Cython smarter internally. Reducing the GC
overhead by avoiding unnecessary support functions sounds valuable.

Is there anything else that you have pending?

I would also like to clean up the documentation for the next major release,
see my e-mail to cython-users.