http://blog.gmane.org/gmane.comp.python.cython.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.python.cython.devel/14908 <pre>Hi! Recently I've found that the following code causes segmentation fault: cdef object f del f print f So the question is: how should that work? global objects are implicitly initialized to None and no CF and no cf analysis is performed for it. So I see three options here: 1. prohibit cglobal deletion 2. set it back to None 3. check for a null value at every reference and assignment </pre> Vitja Makarov 2013-05-24T05:02:20 http://comments.gmane.org/gmane.comp.python.cython.devel/14906 <pre>Hi, Someone please apply this patch (too simple for pull request): diff --git a/Cython/Compiler/ExprNodes.py b/Cython/Compiler/ExprNodes.py index 0406fad..640d002 100755 --- a/Cython/Compiler/ExprNodes.py +++ b/Cython/Compiler/ExprNodes.py &lt; at &gt;&lt; at &gt; -4993,7 +4993,7 &lt; at &gt;&lt; at &gt; class AttributeNode(ExprNode): # creates a corresponding NameNode and returns it, otherwise # returns None. type = self.obj.analyse_as_extension_type(env) - if type: + if type and type.scope: entry = type.scope.lookup_here(self.attribute) if entry and entry.is_cmethod: if type.is_builtin_type: It fixes CompilerCrash (None does not have "lookup_here" method) that I have observed on two occasions: 1) cdef class Name; cimport Name; Name.attr 2) from X cimport Name; Name.attr # cimport_from_pyx is active, Name is a class with errors Makes me wonder if ErrorScope should be introduced to avoid None scope checks. Best regards, Nikita Nemkin </pre> Nikita Nemkin 2013-05-22T09:13:02 http://comments.gmane.org/gmane.comp.python.cython.devel/14899 <pre>Hi! Recently I've started work on new type inference engine. Now it's almost ready and I want to discuss it. It works like this: first infer type for each assignment then for whole entry. It has some advantages over previous algorithm: - it handles assignment cycles, see test_swap() for example - it can infer type using info about assignments on the whole entry: a = 1 b = a a = "str" a is python object and b is integer. Here are testcases that show some new cases it can solve: https://github.com/vitek/cython /blob/_type_inference_new/tests/run/type_inference_new.pyx Here is branch for it https://github.com/vitek/cython /tree/_type_inference_new </pre> Vitja Makarov 2013-05-21T10:26:35 http://comments.gmane.org/gmane.comp.python.cython.devel/14889 <pre>Hello, I ran into an interesting problem today. It doesn't seem like Cython respects the `nogil` statement on extern cpp functions. I am trying to use a blocking I/O function, and am running it in secondary thread so I can use another library function to cancel it. I have tried it both on the `extern` line: cdef extern from "digitalpersona/dpfp_api.h" nogil: uint32_t DPFPGetEvent(dp_uid_t* pDevUID, dp_device_event_t** ppEvent, uint32_t uTimeoutMsec) and on the function itself: cdef extern from "digitalpersona/dpfp_api.h" nogil: uint32_t DPFPGetEvent(dp_uid_t* pDevUID, dp_device_event_t** ppEvent, uint32_t uTimeoutMsec) nogil Either way, this statement still blocks other threads: res = dpfp_api.DPFPGetEvent(pIdDev, &amp;pEvent, dpfp_api.DP_TIMEOUT_INFINITE) While this statement does not: with nogil: res = dpfp_api.DPFPGetEvent(pIdDev, &amp;pEvent, dpfp_api.DP_TIMEOUT_INFINITE) All variables used (res, pIdDev, pEvent) are C variables. Obviously this is not a huge issue, as I can bypass the GIL using `with nogil`. But I figured it would be a good idea to report it anyway. Ryan Pessa AerisPOS Project Manager / Developer Essential Elements &lt;http://www.essential-elements.net/&gt; | AerisPOS&lt;http://www.aerispos.com/&gt; </pre> Ryan Pessa 2013-05-08T18:09:14 http://comments.gmane.org/gmane.comp.python.cython.devel/14878 <pre>Hi, since there's an unpleasant regression in 0.19, I'd like to release 0.19.1 soon. If you have any more fixes that should go in, you may want to apply them now or at least speak up to delay the release. I'm aware of ticket 810, but it doesn't seem like a regression and I don't currently see an obvious simple way to reproduce it. It looks like a classical "last reference dies while still in use" kind of problem to me. Maybe even a bug in Sage rather than Cython that just accidentally worked in older releases, although I'm not saying that there is nothing Cython could do about it. http://trac.cython.org/cython_trac/ticket/810 Ticket 814 (compiler crash during C++ code analysis) would also be worth closing before a release as it might be an easy fix, even though it's not a regression (crashes for me also in 0.18). http://trac.cython.org/cython_trac/ticket/814 I also think that Ticket 775 ("memoryview" name leaks into module namespace) should eventually be fixed as it's annoying and unexpected, although not necessarily right in this release (it's been like this forever). http://trac.cython.org/cython_trac/ticket/775 Anything else? Stefan </pre> Stefan Behnel 2013-05-03T07:29:18 http://comments.gmane.org/gmane.comp.python.cython.devel/14868 <pre>See the example below, the last hunk fails with Cython 0.19. It seems Cython is confusing attribute access with constness. CYTHON=cython echo 'cdef import from *:' &gt; defs.pxd echo ' enum:SIZE' &gt;&gt; defs.pxd echo 'from defs cimport *' &gt; code1.pyx echo 'cdef char buf[SIZE]' &gt;&gt; code1.pyx $CYTHON code1.pyx echo 'cimport defs' &gt; code2.pyx echo 'cdef char buf[defs.SIZE]' &gt;&gt; code2.pyx $CYTHON code2.pyx -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) 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 </pre> Lisandro Dalcin 2013-05-01T07:14:53 http://comments.gmane.org/gmane.comp.python.cython.devel/14867 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP http://sites.google.com/site/worlddump1 organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia richer. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. This fake paper is different from the two fake papers already published (see https://sites.google.com/site/worlddump4 for details) in WORLDCOMP. We MUST say that you should look at the above website if you have any thoughts of participating in WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and threatens the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Prof. Hamid Arabnia makes a lot of tricks. For example, he appeared in a newspaper to fool the public, claiming him a victim of cyber-attack (see Item 8 in Section 5 of above website). Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! We ask Prof. Hamid Arabnia to publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also ask him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 and respond if he has any professional values. Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities at http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. _______________________________________________ cython-devel mailing list cython-devel&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/cython-devel </pre> eliswilson-revL73yDgGBWk0Htik3J/w< at >public.gmane.org 2013-04-30T22:06:53 http://comments.gmane.org/gmane.comp.python.cython.devel/14859 <pre>Hi, While browsing Cython's bugtracker I've found a few issues that should be closed as fixed: http://trac.cython.org/cython_trac/ticket/42 http://trac.cython.org/cython_trac/ticket/94 http://trac.cython.org/cython_trac/ticket/113 http://trac.cython.org/cython_trac/ticket/246 http://trac.cython.org/cython_trac/ticket/358 Best regards, Nikita Nemkin </pre> Nikita Nemkin 2013-04-26T15:53:52 http://comments.gmane.org/gmane.comp.python.cython.devel/14856 <pre>Hi, the packages in the Ubuntu PPA still have 0.18.0 in their name, although they actually build the current master, which is at 0.19. Is there a way to adapt that automatically? Stefan </pre> Stefan Behnel 2013-04-26T06:34:31 http://comments.gmane.org/gmane.comp.python.cython.devel/14854 <pre>Hi, looking at this ticket: http://trac.cython.org/cython_trac/ticket/810 and at the underlying Sage ticket: http://trac.sagemath.org/sage_trac/ticket/14452 ISTM that this crash is not actually related to cdef kwargs but simply to the fact that the C code is now calling directly through the C layer and no longer through Python. The major difference being that Python puts arguments into a tuple that is kept alive for the whole timespan of the call, whereas C just passes in the reference and forgets about it. Since the method in question replaces references internally, it's quite possible that it somehow deletes the last reference to the object that was passed in. I wouldn't really know why, as we specifically guard against these things since somewhere around 0.17 (and comment #7 in the Sage ticket shows an example of that), but maybe this is just a corner case that we failed to handle so far, or maybe the Sage code is doing something 'unexpected' here. Stefan </pre> Stefan Behnel 2013-04-26T05:07:52 http://comments.gmane.org/gmane.comp.python.cython.devel/14847 <pre>Hi Cython devs, Over in scikit-image we have traced an odd problem with a particular Cython file to the 0.19 update of Cython. From at least Cython 0.15.1 (probably earlier) through 0.18, `_mcp.pyx` in `skimage.graph` compiled and executed correctly, passing all package tests on both Python 2.7 and Python 3. After 0.19 was released and the Travis builds began using it, we began getting 100% repeatable errors from the previously clean master branch (example of an otherwise clean Python 2.7&lt;https://travis-ci.org/scikit-image/scikit-image/jobs/6545505&gt;Travis build; the Python 3 build passed&lt;https://travis-ci.org/scikit-image/scikit-image/builds/6545504&gt;all tests). All of these errors/failures trace back to this Cython file. Oddly, the errors only happen on Python 2.7; our Python 3 Travis build passes. We are discussing this issue in scikit-image Github Issue #534&lt;https://github.com/scikit-image/scikit-image/issues/534&gt;; feel free to join the discussion there. The .pyx Cython file is located here&lt;https://github.com/scikit-image/scikit-image/blob/master/skimage/graph/_mcp.pyx&gt;and it has an associated .pxd file here&lt;https://github.com/scikit-image/scikit-image/blob/master/skimage/graph/_mcp.pxd&gt;. It should be noted the file compiles and executes without errors, but its output is now incorrect in Python 2.x. In case the compiled results might be relevant, for your diffing pleasure here is the compiled .c file from Cython 0.18&lt;https://gist.github.com/JDWarner/af4f8ea85dce356ce95c&gt;which passes all tests on both Python 2.7 and Python 3.x, while here is the compiled .c file from Cython 0.19&lt;https://gist.github.com/JDWarner/56d15b7a7527b8d4314e&gt;which produces different, incorrect results in Python 2.7. In the short term we are temporarily forcing Travis to use the 0.18 release of Cython, but that isn't a viable long term solution. It's possible the error is on our end, but seeing as it worked with prior Cython releases we'd appreciate you taking a look. Thanks! </pre> Josh Warner 2013-04-24T06:06:36 http://comments.gmane.org/gmane.comp.python.cython.devel/14845 <pre>Hi again, I am just wondering how to do unit testing on extensions built using Cython with py.test. My problem: The extension module I am working on is installed in our global python environment (inside the build slaves as well as on local machines) already. Before installing a new version of the extension module, I'd like to run the unit tests. However, that way the original module is tested. I am trying to illustrate. Doing TDD I create a new module which will fail the test: torsten&lt; at &gt;sharokan:~/foo$ cat foo.pyx def it_works(): return False torsten&lt; at &gt;sharokan:~/foo$ cat tests/test_foo.py import pprint, foo def test_foo(): pprint.pprint(foo.__file__) assert foo.it_works() torsten&lt; at &gt;sharokan:~/foo$ py.test -v tests ============================================================ test session starts ============================================================ platform linux2 -- Python 2.7.3 -- pytest-2.3.4 -- /opt/dynasdk/loco2-precise/bin/python plugins: cov, capturelog collected 0 items / 1 errors ================================================================== ERRORS =================================================================== ____________________________________________________ ERROR collecting tests/test_foo.py _____________________________________________________ tests/test_foo.py:1: in &lt;module&gt; &gt; import sys, pprint, foo E ImportError: No module named foo ========================================================== 1 error in 0.01 seconds ========================================================== Sure, module foo does not exists. I could use pyximport, but I want to check that the extension itself is correctly built. Easily done: torsten&lt; at &gt;sharokan:~/foo$ python setup.py build_ext -i running build_ext cythoning foo.pyx to foo.c building 'foo' extension creating build creating build/temp.linux-x86_64-2.7 gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/opt/dynasdk/loco2-precise/include/python2.7 -c foo.c -o build/temp.linux-x86_64-2.7/foo.o gcc -pthread -shared build/temp.linux-x86_64-2.7/foo.o -L/opt/dynasdk/loco2-precise/lib -lpython2.7 -o /home/torsten/foo/foo.so But alas, py.test still will not find foo.so, which is now installed into the current directory (due to using the "-i" flag to build_ext). Workaround: Overwrite PYTHONPATH: torsten&lt; at &gt;sharokan:~/foo$ PYTHONPATH=`pwd` py.test ============================================================ test session starts ============================================================ platform linux2 -- Python 2.7.3 -- pytest-2.3.4 plugins: cov, capturelog collected 1 items tests/test_foo.py F ================================================================= FAILURES ================================================================== _________________________________________________________________ test_foo __________________________________________________________________ def test_foo(): pprint.pprint(foo.__file__) &gt; assert foo.it_works() E assert &lt;built-in function it_works&gt;() E + where &lt;built-in function it_works&gt; = foo.it_works tests/test_foo.py:5: AssertionError -------------------------------------------------------------- Captured stdout -------------------------------------------------------------- '/home/torsten/foo/foo.so' ========================================================= 1 failed in 0.02 seconds ========================================================== Now it really loads our extension module and the failure is actually genuine. Let's assume we have the old version installed in our current Python environment: torsten&lt; at &gt;sharokan:~/foo$ python setup.py install [...] creating /usr/opt/dynasdk/loco2-precise/lib/python2.7/site-packages/foo-0.0-py2.7-linux-x86_64.egg Extracting foo-0.0-py2.7-linux-x86_64.egg to /usr/opt/dynasdk/loco2-precise/lib/python2.7/site-packages Adding foo 0.0 to easy-install.pth file Installed /usr/opt/dynasdk/loco2-precise/lib/python2.7/site-packages/foo-0.0-py2.7-linux-x86_64.egg [...] Great. Now let's implement the feature that our test checks: torsten&lt; at &gt;sharokan:~/foo$ vim foo.pyx torsten&lt; at &gt;sharokan:~/foo$ cat foo.pyx def it_works(): return True The unit tests should pass now, after we rebuilt the extension: torsten&lt; at &gt;sharokan:~/foo$ python setup.py build_ext -i running build_ext cythoning foo.pyx to foo.c building 'foo' extension gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/opt/dynasdk/loco2-precise/include/python2.7 -c foo.c -o build/temp.linux-x86_64-2.7/foo.o gcc -pthread -shared build/temp.linux-x86_64-2.7/foo.o -L/opt/dynasdk/loco2-precise/lib -lpython2.7 -o /home/torsten/foo/foo.so torsten&lt; at &gt;sharokan:~/foo$ PYTHONPATH=`pwd` py.test ============================================================ test session starts ============================================================ platform linux2 -- Python 2.7.3 -- pytest-2.3.4 plugins: cov, capturelog collected 1 items tests/test_foo.py F ================================================================= FAILURES ================================================================== _________________________________________________________________ test_foo __________________________________________________________________ def test_foo(): pprint.pprint(foo.__file__) &gt; assert foo.it_works() E assert &lt;built-in function it_works&gt;() E + where &lt;built-in function it_works&gt; = foo.it_works tests/test_foo.py:5: AssertionError -------------------------------------------------------------- Captured stdout -------------------------------------------------------------- '/opt/dynasdk/loco2-precise/lib/python2.7/site-packages/foo-0.0-py2.7-linux-x86_64.egg/foo.so' ========================================================= 1 failed in 0.02 seconds ========================================================== Unfortunately, it doesn't. The unit tests actually uses the installed version of the library, which we only want to replace after our tests pass. Let's try it another way: By creating a virtualenv just for our tests, we should be fine: torsten&lt; at &gt;sharokan:~/foo$ virtualenv --system-site-packages fooenv New python executable in fooenv/bin/python Please make sure you remove any previous custom paths from your /home/torsten/.pydistutils.cfg file. Installing setuptools............done. Installing pip...............done. torsten&lt; at &gt;sharokan:~/foo$ . fooenv/bin/activate (fooenv)torsten&lt; at &gt;sharokan:~/foo$ pip install --upgrade . Unpacking /home/torsten/foo Running setup.py egg_info for package from file:///home/torsten/foo Downloading/unpacking Cython from http://pypi.python.org/packages/source/C/Cython/Cython-0.19.tar.gz#md5=76989337dee4cf7afdcb5cde514423f8 (from foo==0.0) Downloading Cython-0.19.tar.gz (1.4MB): 270kB downloaded ... Good start, but I don't want to recreate the whole thing inside the virtualenv fooenv. This would pull Cython, numpy, scipy, paramiko and more. Any hint how to ensure that we are testing the local version of that extension instead of the installed one? Thanks, Torsten </pre> Torsten Landschoff 2013-04-23T20:51:05 http://comments.gmane.org/gmane.comp.python.cython.devel/14843 <pre> When trying to use strcasecmp from libc.string I get an error compiling with msvc: error C3861: 'strcasecmp': identifier not found It seems MS have decided to call it by another name - _stricmp ...amongst others: http://botsikas.blogspot.co.uk/2011/12/strcasecmp-identifier-not-found- when.html I'm wondering if it's possible for cython to include the mentioned ifdef defines by default or otherwise solve the problem so that code is portable between compilers on Windows? I understand if it's not a high priority issue. The workaround is for me to make sure all our code compiles with mingw which was on the radar anyway. Thanks, Dave </pre> Dave Hirschfeld 2013-04-23T14:56:25 http://comments.gmane.org/gmane.comp.python.cython.devel/14832 <pre>Hi Cython-Developers, I am using Cython to generate a trivial wrapper for a small subset of the (already small) interface of libp11 (see https://github.com/OpenSC/libp11 for information about libp11). I know a bit about Python extension modules and just wanted to avoid writing all that boiler plate code and decided to given Cython a try. The wrapper was done in a day and no big deal, but lately I got random segmentation faults using it. After a day of debugging I found the cause in my use of the __dealloc__ special method. You may now call me stupid, because it is all in the docs: /You need to be careful what you do in a //__dealloc__()//method. By the time your //__dealloc__()//method is called, the object may already have been partially destroyed and may not be in a valid state as far as Python is concerned, so you should avoid invoking any Python operations which might touch the object. In particular, don't call any other methods of the object or do anything which might cause the object to be resurrected. It's best if you stick to just deallocating C data.// / http://docs.cython.org/src/userguide/special_methods.html?highlight=__dealloc__#finalization-method-dealloc But this did not give me the crucial hint: Currently, any references to Python objects *may* be invalid at the time dealloc is called. This is because Cython generates a tp_clear function for each extension type that calls Py_CLEAR for each object reference. What I would really like to have is a possibility to exempt object attributes from being cleared in tp_clear, by adding a modifier to the cdef: *Exempt all attributes:* cdef noclear class Slots: cdef Context context *Exempt a single attribute:* cdef class Slots: cdef noclear Context context This is probably enough of explanation for the Cython experts, but I would still like to explain what happened in my case and a work around for illustration purposes and in the hope, that this will help somebody else at some time. Background When using the libp11 API, the client must create a Context object which is used for most operations. To query the list of slots where a card (token) could be inserted, there is a PKCS11_enumerate_slots function which returns a newly allocated buffer which contains all slots. Unfortunately this means that the resulting Slot objects can not be deallocated individually, only the whole buffer can be released using PKCS11_release_all_slots. This is completely unpythonic which is why I created a special Slots extension type that manages the storage of the Slot instances. When all Slot instances drop their reference to the Slots instance, the refcount of the Slots instance drops to zero and Python will release it automatically. The Slots type then calls the PKCS11_release_all_slots function to release the storage. This is modelled inside the __dealloc__ method for Slots. Unfortunately, a pointer to the context is required for that call. Therefore Slots also keeps a reference to Context object to keep it alive long enough and to identify the underlying C object. But: At the time when __dealloc__ is called, the tp_clear function already has cleared the context reference. Interestingly, it does not use Py_CLEAR as mandated in the Python documentation (see http://docs.python.org/2/c-api/typeobj.html?highlight=py_clear#PyTypeObject.tp_clear and http://docs.python.org/3.3/c-api/typeobj.html?highlight=py_clear#PyTypeObject.tp_clear) but instead redirects all Python objects to Py_NONE, which partially hides the problem. Somehow, this is not deterministic and tp_clear may have been called or not before tp_dealloc, therefore the random crashes. Even more funny: tp_clear seems to get only called if the Slots instance is involved in a reference cycle. Example Code I attached an example Cython project. If you build and install it with Cython 0.19, the following Python code will work: from fakep11 import * def works(): ctx = Context() my_slots = ctx.slots() while my_slots: assert ctx.usage_counter == 1 my_slots.pop() assert ctx.usage_counter == 0 But the following code will crash when the garbage collector runs: def crashes(): ctx = Context() slots = ctx.slots() a = {"slot": slots[0]} b = {"slot": slots[1], "cycle": a} a["cycle"] = b This is because a and b refer to each other, creating a cycle, and both refer to a slot, pulling the Slots instance into the object graph of the cycle. For this reason, tp_clear will be called for slots before tp_dealloc is called, leaving tp_dealloc with invalid data. Conclusion 1. As somebody who wrote Python extension modules manually before, I fell into this trap because I never implemented tp_clear. Reference cycles were a non-issue to me, since the wrapped objects could not refer to Python objects. Interestingly, SWIG does not seem to have any support for calling tp_clear it seems. 2. IMHO tp_clear should really use Py_CLEAR which would at least make this case a solid segfault. 3. Generating tp_clear functions is a feature that can do some harm, there I propose to allow to disable it. Work around For my current project I worked around this problem by managing the Python references manually by declaring them as PyObject* as in this diff: diff -r f2afc4865bbc fakep11.pyx --- a/fakep11.pyx Sat Apr 20 23:43:00 2013 +0200 +++ b/fakep11.pyx Sun Apr 21 23:50:10 2013 +0200 &lt; at &gt;&lt; at &gt; -1,5 +1,10 &lt; at &gt;&lt; at &gt; cimport cython +cdef extern from "Python.h": + ctypedef struct PyObject + void Py_INCREF(PyObject *) + void Py_DECREF(PyObject *) + cdef extern from "fakep11c.h": ctypedef struct fakep11_context: &lt; at &gt;&lt; at &gt; -35,17 +40,19 &lt; at &gt;&lt; at &gt; &lt; at &gt;cython.internal cdef class Slots: - cdef Context context + cdef PyObject *context cdef unsigned int nslots cdef fakep11_slot *slots def __cinit__(self, Context context): - self.context = context + self.context = &lt;PyObject*&gt; context + Py_INCREF(self.context) self.slots = fakep11_enumerate(context.imp, &amp;self.nslots) def __dealloc__(self): print "Slots dealloc" - fakep11_release_all(self.context.imp, self.slots, self.nslots) + fakep11_release_all((&lt;Context&gt;self.context).imp, self.slots, self.nslots) + Py_DECREF(self.context) def as_list(self): l = [None] * self.nslots That way I have full control over the reference counting and can make sure that context is a valid reference when __dealloc__ is called. Please find my fake libp11 wrapper example code attached, as well as a small patch for the documentation documenting the current status. Greetings, Torsten </pre> Torsten Landschoff 2013-04-21T21:57:15 http://comments.gmane.org/gmane.comp.python.cython.devel/14825 <pre>Hi, since the current code base can explicitly express dependencies between utility code sections, do we still need this branch? Or can we close it together with the ticket? ISTM that explicit dependencies are a more general feature than just honouring type hierarchies. Stefan </pre> Stefan Behnel 2013-04-19T20:25:28 http://comments.gmane.org/gmane.comp.python.cython.devel/14811 <pre>Hi, Arguments, return values and properties of type 'bint' appear as 'int' in autogenerated signatures. This is very confusing for the end user and logically wrong. (For one thing, bint and int handle input arguments differently: bint accepts pretty much any Python object, while int requries something numeric.) Would it be acceptable to change bint display presentation to 'bool' ? Note: other primitive types (short, int, float, long long etc) don't have this problem, because they are all numeric and coerce to/from Python numerics in an obvious way. Best regards, Nikita Nemkin </pre> Nikita Nemkin 2013-04-14T09:33:14 http://comments.gmane.org/gmane.comp.python.cython.devel/14809 <pre>Hi, this patch looks ok to me: http://trac.cython.org/cython_trac/ticket/805 Any objections from the C++ users against including it in 0.19? Stefan </pre> Stefan Behnel 2013-04-14T07:40:31 http://comments.gmane.org/gmane.comp.python.cython.devel/14806 <pre>Here are two lines of valid Python: 'ab' 'bc' If I try this in code that I compile with Cython, it throws an exception: TypeError: 'NoneType' object cannot be interpreted as an index </pre> Bryan O'Sullivan 2013-04-13T03:02:23 http://comments.gmane.org/gmane.comp.python.cython.devel/14803 <pre>Dear mailing list In the process of developing a rather large Cython project where we wrap the scientific OpenMS library (http://sourceforge.net/projects/open-ms/) using Cython, we have come across an issue with the C++ code that is generated by Cython. The issue is that Cython generates C++ that is not compatible with the Clang compiler. I hope this is the correct mailing list to report this issue since it seems to be a bug in Cython and not in Clang (after some discussion we have concluded that Clang is most likely correct in rejecting the generated code). Since we do not have access to the issue tracker, we hoped posting our issue here would clear up matters. The issue occurs with the following minimal testcase: from libcpp.vector cimport vector as libcpp_vector from cython.operator cimport dereference as deref, preincrement as inc cdef class TestClass: cdef libcpp_vector[float] inst def __iter__(self): it = self.inst.begin() while it != self.inst.end(): yield deref(it) inc(it) When compiled with Cython to C++, it generates C++ that cannot be compiled with Clang (however it seems that gcc and MSVS accept the code). It seems that the same issue with Clang was already discussed here: https://bugzilla.mozilla.org/show_bug.cgi?id=623303 and the conclusion was that Clang is correct in reporting the code as erroneous. In the above case, the invalid C++ code that gets generated is: p-&gt;__pyx_v_it.std::vector&lt;float&gt;::iterator::~iterator(); The correct code for the above case would probably be (this is just a suggestion, it compiles with gcc and clang on our machines and our tests run through with it): typedef std::vector&lt;float&gt;::iterator _it; p-&gt;__pyx_v_it.~_it(); We have tested it with the 0.18 release as well as the newest 0.19b2 build from github (58131b68dc033fc7ca269d875a2aab2b4e9646a2) and the results were the same. Thanks, Hannes Röst </pre> Hannes Röst 2013-04-12T15:04:01 http://comments.gmane.org/gmane.comp.python.cython.devel/14798 <pre>Hi, The following code (also attached as a .pyx file) fails in the current Cython : cdef class test: pass def main(): cdef test a, b, c, d (a, b) = (c, d) = (None, None) When run, I get the following traceback: In [1]: import assign_test In [2]: assign_test.main() Traceback (most recent call last): File "&lt;ipython-input-2-c2f7599d7b34&gt;", line 1, in &lt;module&gt; assign_test.main() File "assign_test.pyx", line 6, in assign_test.main (assign_test.c:669) (a, b) = (c, d) = (None, None) TypeError: Cannot convert NoneType to assign_test.test I am using the latest Cython development version (from github). Also tested with Cython 0.18. $ git rev-parse HEAD e8bd1789905a58d8224e4be5019be401f360aa54 I don't get an error when I change the assignments to either: (a, b) = (None, None) or a = b = None Is this a bug in Cython? I tried doing a git bisect and it seems like commit ea6a71acb5c79afb080855be1cb6ca30d283ec25 is when the above code started failing (It works with the previous commit). Thanks, Alok </pre> Alok Singhal 2013-04-10T20:36:27 http://comments.gmane.org/gmane.comp.python.cython.devel/14762 <pre>means a memoryview object from another module will fail this check. This is a general problem in Cython that could be worked around for memoryviews, but in general the lack of a Cython runtime is a blessing for distribution purposes and a wart for most other purposes. This seems easy to fix - a Cython runtime would be a python module like cython.runtime that Cython modules imported and used, right? You could emulate this perfectly by just checking for such a module in sys.modules at import time, and injecting a copy if none was found. (With some versioning in the name so modules compiled with different versions of Cython could coexist.) This would be much easier than coming up with elaborate object model hacks, since it just uses existing standard python mechanisms... -n </pre> Nathaniel Smith 2013-04-09T12:25:02 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.python.cython.devel