From torsten.landschoff at dynamore.de Fri Aug 2 00:59:14 2013 From: torsten.landschoff at dynamore.de (Torsten Landschoff) Date: Fri, 02 Aug 2013 00:59:14 +0200 Subject: [Cython] Surprising behaviour wrt. generated tp_clear and tp_dealloc functions In-Reply-To: <51E263D3.3020408@behnel.de> References: <517460BB.5040307@dynamore.de> <5174CB1F.50202@behnel.de> <517519FF.1010206@dynamore.de> <51752407.3070405@behnel.de> <51752560.4080304@dynamore.de> <51752CD1.6070408@behnel.de> <51DDDBBA.3040702@dynamore.de> <51E263D3.3020408@behnel.de> Message-ID: Hi again, On 07/14/2013 10:39 AM, Stefan Behnel wrote: > Torsten Landschoff, 11.07.2013 00:10: >> I attached my current (trivial) patch. Currently I only support a decorator >> >> @cython.noclear >> cdef class ... >> >> to inhibit generation of tp_clear. > Thanks, looks ok to me. Please open a pull request on github for it. I reworked it a bit, pull request is here: https://github.com/cython/cython/pull/248 Sorry it took so long, real life takes it's toll ;-) > I think that name is as good as any. It could be "no_gc_clear", if you > find that clearer. It hints at GC, at least. That's what I did. > I think that should be part of the name somehow. Please also document > it somewhere in the extension types doc section (in the user guide): > https://github.com/cython/cython/blob/master/docs/src/userguide/extension_types.rst Done. Please advise if you think it needs improvement - I have a hard time to describe complex facts in concise form. >> How should the decorator to completely disable GC for a class be called? >> @cython.nogc? > +1 I did not yet implement this. Greetings, Torsten -- DYNAmore Gesellschaft fuer Ingenieurdienstleistungen mbH Torsten Landschoff Office Dresden Tel: +49-(0)351-312002-10 Fax: +49-(0)351-312002-29 mailto:torsten.landschoff at dynamore.de http://www.dynamore.de DYNAmore Gesellschaft f?r FEM Ingenieurdienstleistungen mbH Registration court: Stuttgart, HRB 733694 Managing director: Prof. Dr. Karl Schweizerhof, Dipl.-Math. Ulrich Franz From robertwb at gmail.com Sat Aug 3 07:36:48 2013 From: robertwb at gmail.com (Robert Bradshaw) Date: Fri, 2 Aug 2013 22:36:48 -0700 Subject: [Cython] patch for #655 In-Reply-To: <20130723092515.GG3696@bin.d-labs.de> References: <20130625083406.GM11552@bin.d-labs.de> <51CBE294.50803@behnel.de> <20130627082610.GL3756@bin.d-labs.de> <20130627172556.GD3356@bin.d-labs.de> <20130627191832.GE3356@bin.d-labs.de> <20130627210602.GH3356@bin.d-labs.de> <51CD1391.3070606@behnel.de> <20130723092515.GG3696@bin.d-labs.de> Message-ID: On Tue, Jul 23, 2013 at 2:25 AM, Felix Salfelder wrote: > On Fri, Jun 28, 2013 at 06:39:45AM +0200, Stefan Behnel wrote: >> > the only thing that will affect the user (and which i should mention) >> > is: make uses file extensions to determine file types. particularly, i >> > have not found a portable hack that allows the use of .pyx for both .c >> > and .cpp within the scope of one makefile yet... >> >> That's unfortunate, but not too serious either. > > its bearable, and it's just automake. manually created makefiles are not > affected. why does cython use .pyx for two different things? what would > be the canonical extension for C++ cython files? i've chosen to use .pyxx, > any better options? Though there are some features only available with C++, I don't consider this "two different things" as the similarities far, far outweigh the differences. >> Hmm, does that mean you either have to create them manually before the >> first run, and/or you have to manually collect all dependency files for the >> "include" list? And then keep track of them yourself when you add new files? > > my goal is to use autotools for that sort of stuff. but yes, you can > always do everything manually. > >> I suppose you could also use a wildcard file search to build the list of >> include files? > > wildcards are seen as bad [1]. might be a matter of taste, of course. > with manually created makefiles, you can do what you like best, of > course. > >> > (automake will call the linker seperately, to increase portability or >> > something) > >> If you want this feature to go in, I think you should write up >> documentation for it, so that other people can actually use it as well. > > i have. type cython --help. this should be copied into the manpage, but > we need to agree on the choice of option names first (and some other > details, see the push request on github). > >> Even writing a correct makefile requires a huge amount of digging into >> distutils. > > makefiles are documented in the make manual of your favourite make > implementation. I don't know why you would want to dig into distutils. To expand on what Stefan wrote, distutils automatically figures out the flags, linker options, headers, etc. to make an extension compatible with that specific Python on your system, which one would either have to do manually or "extract" from distutils otherwise. - Robert From stefan_ml at behnel.de Sat Aug 3 18:24:35 2013 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sat, 03 Aug 2013 18:24:35 +0200 Subject: [Cython] PEP 442: safe object finalisation Message-ID: <51FD2EC3.5030402@behnel.de> Hi, CPython 3.4 will have a new way to handle object finalisation. http://www.python.org/dev/peps/pep-0442/ 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. Stefan From torsten.landschoff at dynamore.de Mon Aug 5 10:02:44 2013 From: torsten.landschoff at dynamore.de (Torsten Landschoff) Date: Mon, 05 Aug 2013 10:02:44 +0200 Subject: [Cython] PEP 442: safe object finalisation In-Reply-To: <51FD2EC3.5030402@behnel.de> References: <51FD2EC3.5030402@behnel.de> Message-ID: Hi Stefan, On 08/03/2013 06:24 PM, Stefan Behnel wrote: > CPython 3.4 will have a new way to handle object finalisation. > > http://www.python.org/dev/peps/pep-0442/ > > 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. I read the PEP and was wondering about the performance of this part: 1. *The CI is traversed again to determine if it is still isolated. If it is determined that at least one object in CI is now reachable from outside the CI, this collection is aborted and the whole CI is resurrected. Otherwise, proceed.* AFAICT it will not suffice to traverse the CI here. Instead, all active objects must be traversed which seems to be quite expensive. Does this mean that you will not pull my gc_no_clear changes from https://github.com/cython/cython/pull/248 in favor of this better fix? Or should I update it so that gc_no_clear only has an affect on Python < 3.4? Greetings, Torsten -- DYNAmore Gesellschaft fuer Ingenieurdienstleistungen mbH Torsten Landschoff Office Dresden Tel: +49-(0)351-312002-10 Fax: +49-(0)351-312002-29 mailto:torsten.landschoff at dynamore.de http://www.dynamore.de DYNAmore Gesellschaft f?r FEM Ingenieurdienstleistungen mbH Registration court: Stuttgart, HRB 733694 Managing director: Prof. Dr. Karl Schweizerhof, Dipl.-Math. Ulrich Franz -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan_ml at behnel.de Mon Aug 5 10:40:56 2013 From: stefan_ml at behnel.de (Stefan Behnel) Date: Mon, 05 Aug 2013 10:40:56 +0200 Subject: [Cython] PEP 442: safe object finalisation In-Reply-To: References: <51FD2EC3.5030402@behnel.de> Message-ID: <51FF6518.4090201@behnel.de> Torsten Landschoff, 05.08.2013 10:02: > On 08/03/2013 06:24 PM, Stefan Behnel wrote: >> CPython 3.4 will have a new way to handle object finalisation. >> >> http://www.python.org/dev/peps/pep-0442/ >> >> 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. > I read the PEP and was wondering about the performance of this part: > > 1. *The CI is traversed again to determine if it is still isolated. If > it is determined that at least one object in CI is now reachable > from outside the CI, this collection is aborted and the whole CI is > resurrected. Otherwise, proceed.* > > AFAICT it will not suffice to traverse the CI here. Instead, all active > objects must be traversed which seems to be quite expensive. My attempts to implement support for this suggested that this feature is not entirely thought out yet. I think it needs some more discussion on the python-dev list (despite the fact that the PEP has been accepted already). > Does this mean that you will not pull my gc_no_clear changes from > https://github.com/cython/cython/pull/248 in favor of this better fix? > Or should I update it so that gc_no_clear only has an affect on Python < > 3.4? I see the two features as completely unrelated. All that should really change with PEP 442 is the time at which the finalisation runs during cyclic garbage collection, iff the type supports GC. Stefan From felix at salfelder.org Mon Aug 5 11:32:07 2013 From: felix at salfelder.org (Felix Salfelder) Date: Mon, 5 Aug 2013 11:32:07 +0200 Subject: [Cython] patch for #655 In-Reply-To: References: <20130627082610.GL3756@bin.d-labs.de> <20130627172556.GD3356@bin.d-labs.de> <20130627191832.GE3356@bin.d-labs.de> <20130627210602.GH3356@bin.d-labs.de> <51CD1391.3070606@behnel.de> <20130723092515.GG3696@bin.d-labs.de> Message-ID: <20130805093207.GJ32316@bin.d-labs.de> On Fri, Aug 02, 2013 at 10:36:48PM -0700, Robert Bradshaw wrote: > > its bearable, and it's just automake. manually created makefiles are not > > affected. why does cython use .pyx for two different things? what would > > be the canonical extension for C++ cython files? i've chosen to use .pyxx, > > any better options? > > Though there are some features only available with C++, I don't > consider this "two different things" as the similarities far, far > outweigh the differences. well, there are two build chains .pyx->.c->.so and .pyx->.cc->.so. without additional information, you cannot tell how to resolve .pyx->.so. usually (outside distutils) there's a tendency towards using different suffixes for different purposes. > To expand on what Stefan wrote, distutils automatically figures out > the flags, linker options, headers, etc. to make an extension > compatible with that specific Python on your system, which one would > either have to do manually or "extract" from distutils otherwise. this has already been implemented (outside and without and before distutils). see [1] for how it may work for python extensions. it a bit beyond the scope of cython and really beyond the scope of my proposed patch. regards felix [1] www.gnu.org/software/automake/manual/html_node/Python.html From dalcinl at gmail.com Mon Aug 5 21:00:49 2013 From: dalcinl at gmail.com (Lisandro Dalcin) Date: Mon, 5 Aug 2013 16:00:49 -0300 Subject: [Cython] Git tag for 0.19.1? Message-ID: I cannot find the tag 0.19.1 in the repository? Did you forget to push it? -- 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 From stefan_ml at behnel.de Tue Aug 6 08:55:05 2013 From: stefan_ml at behnel.de (Stefan Behnel) Date: Tue, 06 Aug 2013 08:55:05 +0200 Subject: [Cython] Git tag for 0.19.1? In-Reply-To: References: Message-ID: <52009DC9.5060008@behnel.de> Lisandro Dalcin, 05.08.2013 21:00: > I cannot find the tag 0.19.1 in the repository? Did you forget to push it? Yes, apparently. Thanks for the reminder. Stefan From stefan_ml at behnel.de Tue Aug 6 09:08:42 2013 From: stefan_ml at behnel.de (Stefan Behnel) Date: Tue, 06 Aug 2013 09:08:42 +0200 Subject: [Cython] Fwd: [cython] no_gc_clear implementation (disable tp_clear) + doc and tests (#248) In-Reply-To: References: Message-ID: <5200A0FA.3050007@behnel.de> Hi, this pull request looks good to me. Any objections to merging it in? Stefan -------- 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 https://github.com/Bluehorn/cython master Or you can view, comment on it, or merge it online at: https://github.com/cython/cython/pull/248 -- Commit Summary -- * Change tp_clear generation to clear to NULL. * Add decorator @gc_no_clear to disable tp_clear slot. -- File Changes -- M Cython/Compiler/ModuleNode.py (12) M Cython/Compiler/Options.py (3) M Cython/Compiler/Symtab.py (7) M Cython/Compiler/TypeSlots.py (10) M docs/src/userguide/extension_types.rst (37) A tests/run/clear_to_null.pyx (68) A tests/run/gc_no_clear.pyx (42) -- Patch Links -- https://github.com/cython/cython/pull/248.patch https://github.com/cython/cython/pull/248.diff From stefan_ml at behnel.de Thu Aug 8 05:50:29 2013 From: stefan_ml at behnel.de (Stefan Behnel) Date: Thu, 08 Aug 2013 05:50:29 +0200 Subject: [Cython] PEP 442: safe object finalisation In-Reply-To: <51FD2EC3.5030402@behnel.de> References: <51FD2EC3.5030402@behnel.de> Message-ID: <52031585.9010802@behnel.de> Stefan Behnel, 03.08.2013 18:24: > CPython 3.4 will have a new way to handle object finalisation. > > http://www.python.org/dev/peps/pep-0442/ > > 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. ... and I found out that there is no guarantee that tp_finalize() gets called. It's meant to map 1:1 to the __del__() Python method, so Python subtypes have to explicitly call their supertype's __del__() method, otherwise it won't be executed. I don't think that's suitable for the use case in Cython, so we should stick with tp_dealloc(). Stefan From stefan_ml at behnel.de Sat Aug 10 20:39:42 2013 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sat, 10 Aug 2013 20:39:42 +0200 Subject: [Cython] new "cythonize" script Message-ID: <520688EE.5080306@behnel.de> Hi, I added a script as "bin/cythonize" that acts as a frontend for the cythonize() compilation tool (and distutils' build_ext). https://github.com/cython/cython/blob/master/bin/cythonize One cool feature is that you can use it to recursively compile packages: cythonize -i -k Cython will translate, compile and link any .py files it finds in the Cython package in-place (-i), ignoring anything that fails to compile (-k). If you pass "--lenient", it ignores some compile time errors in favour of Python compatibility. It also works on glob patterns etc. I'm sure there's lots of features missing to make it nicely usable, so please give it a try and speak up if you miss something. Improvements (in the form of ideas and/or pull requests) are warmly appreciated. Stefan From robertwb at gmail.com Sun Aug 11 08:47:48 2013 From: robertwb at gmail.com (Robert Bradshaw) Date: Sat, 10 Aug 2013 23:47:48 -0700 Subject: [Cython] [cython-users] new "cythonize" script In-Reply-To: <520688EE.5080306@behnel.de> References: <520688EE.5080306@behnel.de> Message-ID: On Sat, Aug 10, 2013 at 11:39 AM, Stefan Behnel wrote: > Hi, > > I added a script as "bin/cythonize" that acts as a frontend for the > cythonize() compilation tool (and distutils' build_ext). > > https://github.com/cython/cython/blob/master/bin/cythonize > > One cool feature is that you can use it to recursively compile packages: > > cythonize -i -k Cython > > will translate, compile and link any .py files it finds in the Cython > package in-place (-i), ignoring anything that fails to compile (-k). If you > pass "--lenient", it ignores some compile time errors in favour of Python > compatibility. It also works on glob patterns etc. > > I'm sure there's lots of features missing to make it nicely usable, so > please give it a try and speak up if you miss something. Improvements (in > the form of ideas and/or pull requests) are warmly appreciated. > Cool. I was actually thinking something like this would be useful; no complaints you beat me to it :). - Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From robertwb at gmail.com Tue Aug 13 06:13:09 2013 From: robertwb at gmail.com (Robert Bradshaw) Date: Mon, 12 Aug 2013 21:13:09 -0700 Subject: [Cython] [cython-users] Confused by user's guide In-Reply-To: <0b790bb9-15f2-4032-ba7b-3862920b18f4@googlegroups.com> References: <893c622d-e855-4445-b360-364bbab1c3f5@googlegroups.com> <5208676E.2000003@behnel.de> <0b790bb9-15f2-4032-ba7b-3862920b18f4@googlegroups.com> Message-ID: On Mon, Aug 12, 2013 at 1:37 AM, Zak wrote: > I bet some people are still confused, because I would have been confused if > I read that a few months ago. Let me explain with code: > > # This is a Python function: > def do_math(top, bottom): > return top / bottom > > # This is also a Python function: > def do_math2(int top, int bottom): > return top / bottom > > # The function do_math2 above is "actually" doing > # something like this: > def do_math3(top_temp, bottom_temp): > cdef int top = top_temp > cdef int bottom = bottom_temp > return top / bottom > > All 3 functions above are Python functions, they take Python objects as > arguments and they return a Python object. The static type annotations in > do_math2 can be thought of as syntactic sugar - these type annotations do > not change the call signature of the function, they just tell the function > to immediately convert those arguments into C integers. When the function is > called, it is called with Python objects for top and bottom. But inside the > function, it will use fast C integers for top and bottom. Without this > syntactic sugar, you would be forced to do a renaming dance like that shown > in do_math3. Good explanation. These days do_mat2 actually equivalent to def do_math2(top_temp, bottom_temp): cdef int top = top_temp cdef int bottom = bottom_temp return do_math_c(top, bottom) cdef do_math_c(int top, int bottom): return top / bottom which doesn't really matter to the user except that there may be some cases (in the future) where we can extract and call do_math_c directly. Of course, this is exactly what cpdef is, which has got me thinking whether we need a separate keyword for this, or if we could simply make all def functions cpdef automatically. One place that's different is for exported cdef classes where c(p)def methods must be declared in the .pxd file, but we could perhaps handle this case by allowing them to be declared as plain cdef (or "def") methods there. Does anyone see any drawbacks to this? (I suppose there's a little overhead in the check-if-overridden dispatch.) - Robert From stefan_ml at behnel.de Tue Aug 13 06:58:43 2013 From: stefan_ml at behnel.de (Stefan Behnel) Date: Tue, 13 Aug 2013 06:58:43 +0200 Subject: [Cython] [cython-users] Confused by user's guide In-Reply-To: References: <893c622d-e855-4445-b360-364bbab1c3f5@googlegroups.com> <5208676E.2000003@behnel.de> <0b790bb9-15f2-4032-ba7b-3862920b18f4@googlegroups.com> Message-ID: <5209BD03.1080009@behnel.de> Robert Bradshaw, 13.08.2013 06:13: > def do_math2(top_temp, bottom_temp): > cdef int top = top_temp > cdef int bottom = bottom_temp > return do_math_c(top, bottom) > > cdef do_math_c(int top, int bottom): > return top / bottom > > which doesn't really matter to the user except that there may be some > cases (in the future) where we can extract and call do_math_c > directly. > > Of course, this is exactly what cpdef is, which has got me thinking > whether we need a separate keyword for this, or if we could simply > make all def functions cpdef automatically. One place that's different > is for exported cdef classes where c(p)def methods must be declared in > the .pxd file, but we could perhaps handle this case by allowing them > to be declared as plain cdef (or "def") methods there. Does anyone see > any drawbacks to this? (I suppose there's a little overhead in the > check-if-overridden dispatch.) We could detect which def functions/methods are actually being called inside of the module, and then only drop those calls into C. We already do this for final classes. I think the main problem is the way cpdef is currently implemented. It declares a cdef function with a def wrapper. If it declared a def function instead, it would be easier to do the switch later in the pipeline for normal def functions. But as you noted, if we just unified that into always declaring the two entry points up-front, for both def and cpdef functions, preferably using the existing signature override mechanism, then we'd have the means to switch at any point. Trying to do this across modules is less straight forward, as it would override existing user declarations in .pxd files (if they exist). It could be done if we automatically generate a .pxd from a .pyx file, though. Stefan From robertwb at gmail.com Wed Aug 14 07:21:19 2013 From: robertwb at gmail.com (Robert Bradshaw) Date: Tue, 13 Aug 2013 22:21:19 -0700 Subject: [Cython] [cython-users] Confused by user's guide In-Reply-To: <5209BD03.1080009@behnel.de> References: <893c622d-e855-4445-b360-364bbab1c3f5@googlegroups.com> <5208676E.2000003@behnel.de> <0b790bb9-15f2-4032-ba7b-3862920b18f4@googlegroups.com> <5209BD03.1080009@behnel.de> Message-ID: On Mon, Aug 12, 2013 at 9:58 PM, Stefan Behnel wrote: > Robert Bradshaw, 13.08.2013 06:13: >> def do_math2(top_temp, bottom_temp): >> cdef int top = top_temp >> cdef int bottom = bottom_temp >> return do_math_c(top, bottom) >> >> cdef do_math_c(int top, int bottom): >> return top / bottom >> >> which doesn't really matter to the user except that there may be some >> cases (in the future) where we can extract and call do_math_c >> directly. >> >> Of course, this is exactly what cpdef is, which has got me thinking >> whether we need a separate keyword for this, or if we could simply >> make all def functions cpdef automatically. One place that's different >> is for exported cdef classes where c(p)def methods must be declared in >> the .pxd file, but we could perhaps handle this case by allowing them >> to be declared as plain cdef (or "def") methods there. Does anyone see >> any drawbacks to this? (I suppose there's a little overhead in the >> check-if-overridden dispatch.) > > We could detect which def functions/methods are actually being called > inside of the module, and then only drop those calls into C. We already do > this for final classes. Yep. We could dynamically expose/detect this across modules as well (including callables from projects like numba once we define a common ABI). > I think the main problem is the way cpdef is currently implemented. It > declares a cdef function with a def wrapper. If it declared a def function > instead, it would be easier to do the switch later in the pipeline for > normal def functions. But as you noted, if we just unified that into always > declaring the two entry points up-front, for both def and cpdef functions, > preferably using the existing signature override mechanism, then we'd have > the means to switch at any point. Yes, I'm imagining we'd unify this by always creating def functions and which optionally C entry point as well. Maybe cpdef would become a synonym for def and the language could be thus simplified. (It is somewhat annoying that "cdef" and "def" are parsed so differently.) We would need to augment def to allow a return type as well as the gil and except clauses (so it's more like getting rid of def and renaming cpdef to def). > Trying to do this across modules is less straight forward, as it would > override existing user declarations in .pxd files (if they exist). It could > be done if we automatically generate a .pxd from a .pyx file, though. Ideally, you could declare everything as cdef in your pxd file, and make a choice as to whether to use cdef or def in your pyx file. Those def functions not declared in the pxd file just wouldn't get a slot in the vtab. This may not be possible (without additional overhead) due to the need to support overloading in Python space whenever a superclass creates a def wrapper, so perhaps we would allow cdef and def members in the class declaration. When pxd files are generated from pyx, or one does cimports from pyx directly, this becomes even less of an issue. - Robert From yi.codeplayer at gmail.com Sat Aug 17 12:31:14 2013 From: yi.codeplayer at gmail.com (yi huang) Date: Sat, 17 Aug 2013 18:31:14 +0800 Subject: [Cython] A bug when declare array. Message-ID: I use cython 0.19.1, when compile following code: cdef void some_function(): cdef char buf[sizeof(long)*8/3+6] Got error message: Error compiling Cython file: ------------------------------------------------------------ ... cdef void some_function(): cdef char buf[sizeof(long)*8/3+6] ^ ------------------------------------------------------------ /tmp/test.pyx:2:17: Variable type 'char []' is incomplete From robertwb at gmail.com Thu Aug 22 06:01:39 2013 From: robertwb at gmail.com (Robert Bradshaw) Date: Wed, 21 Aug 2013 21:01:39 -0700 Subject: [Cython] A bug when declare array. In-Reply-To: References: Message-ID: On Sat, Aug 17, 2013 at 3:31 AM, yi huang wrote: > I use cython 0.19.1, when compile following code: > > cdef void some_function(): > cdef char buf[sizeof(long)*8/3+6] > > Got error message: > > Error compiling Cython file: > ------------------------------------------------------------ > ... > cdef void some_function(): > cdef char buf[sizeof(long)*8/3+6] > ^ > ------------------------------------------------------------ > > /tmp/test.pyx:2:17: Variable type 'char []' is incomplete That's an interesting one... it's a compile time value at C compilation time, but not a Cython compilation time. I don't have a quick fix. - Robert From matej at laitl.cz Fri Aug 23 01:59:38 2013 From: matej at laitl.cz (=?utf-8?B?TWF0xJtq?= Laitl) Date: Fri, 23 Aug 2013 01:59:38 +0200 Subject: [Cython] Likely bug: compilation failure on aliased cimport + subclass interaction In-Reply-To: <44428308.0FvcZr1EEr@edgy> References: <44428308.0FvcZr1EEr@edgy> Message-ID: <91816413.rhUyuslheZ@edgy> On 23.?8.?2013 Mat?j Laitl wrote: > I'm attaching a more complete testcase which I'll also submit as a review > request for convenience. *cough*, really attaching the second time. Mat?j -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-testcase-for-cimport-alias-subclass-bug.patch Type: text/x-patch Size: 1285 bytes Desc: not available URL: From matej at laitl.cz Fri Aug 23 01:44:48 2013 From: matej at laitl.cz (=?utf-8?B?TWF0xJtq?= Laitl) Date: Fri, 23 Aug 2013 01:44:48 +0200 Subject: [Cython] Likely bug: compilation failure on aliased cimport + subclass interaction Message-ID: <44428308.0FvcZr1EEr@edgy> Hi, it seems that when I do: > cimport foo as f > > cdef class DerivedClass(f.BaseClass): > pass I get following compilation errors: > 3:5: 'BaseClass' is not declared > 3:5: 'f.pxd' not found which looks like a bug to me. When I use plain "cimport foo" + "foo.BaseClass" or "from foo cimport BaseClass" + "BaseClass", it works as expected. Cython version 0.20dev add8091340e (git describe: 0.19-324-gadd8091) I'm attaching a more complete testcase which I'll also submit as a review request for convenience. Regards, Mat?j Laitl From felix at salfelder.org Sun Aug 25 16:52:31 2013 From: felix at salfelder.org (Felix Salfelder) Date: Sun, 25 Aug 2013 16:52:31 +0200 Subject: [Cython] bug in cythonize dependency tracking? Message-ID: <20130825145231.GG22971@bin.d-labs.de> Hi there. Lets say, i have foo.pyx. and use cythonize() to generate foo.c. Calling cythonize() a second time will correctly do nothing, because foo.c has been modified after foo.pyx. If I now add foo.pxd, cythonize will correctly update foo.c. In general foo.c now looks different. But: Deleting foo.pxd and running cythonize another time will fail (=do nothing) and leave foo.c in the wrong state. This might be a bug, depending on whether cythonize is meant to refresh output files consistently. regards felix From stefan_ml at behnel.de Sun Aug 25 20:08:50 2013 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sun, 25 Aug 2013 20:08:50 +0200 Subject: [Cython] bug in cythonize dependency tracking? In-Reply-To: <20130825145231.GG22971@bin.d-labs.de> References: <20130825145231.GG22971@bin.d-labs.de> Message-ID: <521A4832.2000102@behnel.de> Felix Salfelder, 25.08.2013 16:52: > Lets say, i have foo.pyx. and use cythonize() to generate foo.c. > Calling cythonize() a second time will correctly do nothing, because > foo.c has been modified after foo.pyx. > > If I now add foo.pxd, cythonize will correctly update foo.c. In general > foo.c now looks different. But: Deleting foo.pxd and running cythonize > another time will fail (=do nothing) and leave foo.c in the wrong state. > > This might be a bug, depending on whether cythonize is meant to refresh > output files consistently. May not really be a bug, but the current dependency tracking has its limits, yes. Another issue is that it doesn't recompile if you pass different compiler options. That's annoying when you want to try out different directives, e.g. for benchmarking their impact. Both would require some additional tracking of the original compilation environment. OTOH, there's a "force" option (both in distutils and cythonize()) that you can use when you know something relevant changed and want to rebuild everything. Stefan From felix at salfelder.org Sun Aug 25 20:54:50 2013 From: felix at salfelder.org (Felix Salfelder) Date: Sun, 25 Aug 2013 20:54:50 +0200 Subject: [Cython] bug in cythonize dependency tracking? In-Reply-To: <521A4832.2000102@behnel.de> References: <20130825145231.GG22971@bin.d-labs.de> <521A4832.2000102@behnel.de> Message-ID: <20130825185450.GH22971@bin.d-labs.de> On Sun, Aug 25, 2013 at 08:08:50PM +0200, Stefan Behnel wrote: > > This might be a bug, depending on whether cythonize is meant to refresh > > output files consistently. > > May not really be a bug, but the current dependency tracking has its > limits, yes. > > Another issue is that it doesn't recompile if you pass different compiler > options. That's annoying when you want to try out different directives, > e.g. for benchmarking their impact. The difference is, a file may get "lost" accidentally (bogus rebase?) or intentionally (git pull), without the users knowledge. In the benchmarking case the user knowingly wants to rebuild. > Both would require some additional tracking of the original compilation > environment. Writing out dependency information during the build... btw: please somebody help complete the -MF patch [1]. Eventually, you might want to use the created makefiles for dependency tracking. > OTOH, there's a "force" option (both in distutils and cythonize()) that you > can use when you know something relevant changed and want to rebuild > everything. In huge projects one usually just wants to recompile selectively (per directory). Is this possible with distutils? thanks felix [1] https://github.com/cython/cython/pull/243 From stefan_ml at behnel.de Mon Aug 26 08:48:40 2013 From: stefan_ml at behnel.de (Stefan Behnel) Date: Mon, 26 Aug 2013 08:48:40 +0200 Subject: [Cython] bug in cythonize dependency tracking? In-Reply-To: <20130825185450.GH22971@bin.d-labs.de> References: <20130825145231.GG22971@bin.d-labs.de> <521A4832.2000102@behnel.de> <20130825185450.GH22971@bin.d-labs.de> Message-ID: <521AFA48.9030200@behnel.de> Felix Salfelder, 25.08.2013 20:54: > On Sun, Aug 25, 2013 at 08:08:50PM +0200, Stefan Behnel wrote: >> OTOH, there's a "force" option (both in distutils and cythonize()) that you >> can use when you know something relevant changed and want to rebuild >> everything. > > In huge projects one usually just wants to recompile selectively (per > directory). Is this possible with distutils? No. You can try the cythonize script that I added to the git master recently. It also has a -f option now, and you can pass it a package directory to compile. Stefan From sturla at molden.no Tue Aug 27 09:43:38 2013 From: sturla at molden.no (Sturla Molden) Date: Tue, 27 Aug 2013 09:43:38 +0200 Subject: [Cython] A bug when declare array. In-Reply-To: References: Message-ID: Den 22. aug. 2013 kl. 06:01 skrev Robert Bradshaw : > On Sat, Aug 17, 2013 at 3:31 AM, yi huang wrote: >> I use cython 0.19.1, when compile following code: >> >> cdef void some_function(): >> cdef char buf[sizeof(long)*8/3+6] >> >> Got error message: >> >> Error compiling Cython file: >> ------------------------------------------------------------ >> ... >> cdef void some_function(): >> cdef char buf[sizeof(long)*8/3+6] >> ^ >> ------------------------------------------------------------ >> >> /tmp/test.pyx:2:17: Variable type 'char []' is incomplete > > That's an interesting one... it's a compile time value at C > compilation time, but not a Cython compilation time. I don't have a > quick fix. > That's an annoying error. I have never encountered it, but still it annoys me :-( A quick fix is to use alloca instead cdef char *buf = alloca(sizeof(long)*8/3+6) but beware that sizeof(buf) will be different. Sturla From yi.codeplayer at gmail.com Tue Aug 27 10:19:03 2013 From: yi.codeplayer at gmail.com (yi huang) Date: Tue, 27 Aug 2013 16:19:03 +0800 Subject: [Cython] A bug when declare array. In-Reply-To: References:

Message-ID: I just chooses a large enough buffer size, there is not much to waste anyway. On Tue, Aug 27, 2013 at 3:43 PM, Sturla Molden wrote: > > > > Den 22. aug. 2013 kl. 06:01 skrev Robert Bradshaw : > >> On Sat, Aug 17, 2013 at 3:31 AM, yi huang wrote: >>> I use cython 0.19.1, when compile following code: >>> >>> cdef void some_function(): >>> cdef char buf[sizeof(long)*8/3+6] >>> >>> Got error message: >>> >>> Error compiling Cython file: >>> ------------------------------------------------------------ >>> ... >>> cdef void some_function(): >>> cdef char buf[sizeof(long)*8/3+6] >>> ^ >>> ------------------------------------------------------------ >>> >>> /tmp/test.pyx:2:17: Variable type 'char []' is incomplete >> >> That's an interesting one... it's a compile time value at C >> compilation time, but not a Cython compilation time. I don't have a >> quick fix. >> > > That's an annoying error. I have never encountered it, but still it annoys me :-( > > A quick fix is to use alloca instead > > cdef char *buf = alloca(sizeof(long)*8/3+6) > > but beware that sizeof(buf) will be different. > > Sturla > > > > > > _______________________________________________ > cython-devel mailing list > cython-devel at python.org > http://mail.python.org/mailman/listinfo/cython-devel -- http://yi-programmer.com/ From stefan_ml at behnel.de Thu Aug 29 07:03:01 2013 From: stefan_ml at behnel.de (Stefan Behnel) Date: Thu, 29 Aug 2013 07:03:01 +0200 Subject: [Cython] Problem with final cdef methods Message-ID: <521ED605.8040005@behnel.de> Hi, I noticed two problems with final cdef methods. When overriding a normal cdef method with a final cdef method, you currently get a C compiler warning about a call with the wrong 'self' type, and when you call them before you declare them in your code, you get an error because the method is not forward declared. http://trac.cython.org/cython_trac/ticket/819 I think this suggests that we should try to come up with a cleaner way to integrate this feature into the function overloading architecture rather than just remembering their cname and call that. Stefan From vitja.makarov at gmail.com Thu Aug 29 07:30:36 2013 From: vitja.makarov at gmail.com (Vitja Makarov) Date: Thu, 29 Aug 2013 09:30:36 +0400 Subject: [Cython] Problem with final cdef methods In-Reply-To: <521ED605.8040005@behnel.de> References: <521ED605.8040005@behnel.de> Message-ID: 2013/8/29 Stefan Behnel : > Hi, > > I noticed two problems with final cdef methods. When overriding a normal > cdef method with a final cdef method, you currently get a C compiler > warning about a call with the wrong 'self' type, and when you call them > before you declare them in your code, you get an error because the method > is not forward declared. > > http://trac.cython.org/cython_trac/ticket/819 > > I think this suggests that we should try to come up with a cleaner way to > integrate this feature into the function overloading architecture rather > than just remembering their cname and call that. > Hi Stefan, +1, current final implementation isn't clear enough and seems to be a hack to me -- vitja. From robertwb at gmail.com Thu Aug 29 00:11:56 2013 From: robertwb at gmail.com (Robert Bradshaw) Date: Wed, 28 Aug 2013 15:11:56 -0700 Subject: [Cython] [cython-users] Re: wiki spam In-Reply-To: References: <15841ce0-2330-4d97-9e4c-84231d5933dd@googlegroups.com>

Message-ID: On Wed, Aug 28, 2013 at 11:53 AM, William Stein wrote: > On Wed, Aug 28, 2013 at 10:12 AM, Lars Buitinck wrote: >> 2013/8/28 : >>> On Wednesday, August 28, 2013 10:29:35 AM UTC-4, Josh Ayers wrote: >>>> >>>> I just noticed one of the pages on the Cython wiki was changed to spam. >>>> See the page history below. I reverted it, but it will probably happen >>>> again. It may be time to upgrade the captcha used for registering new >>>> accounts. >> >> Man, there's a lot of spam on that wiki (see >> http://wiki.cython.org/RecentChanges). Did you consider moving to a >> GitHub wiki instead? > > As the owner of the hardware on which the cython wiki is running, I > think this is well worth considering. If somebody wants to do it, > I'm happy to tar up the actual wiki install for them, so they can > somehow try to auto-convert all the pages... +1 Spam has increased a lot lately. What I really would like is a publicly editable wiki whose changes have to go through an approval first (e.g. a pull request). Unfortunately, despite expectations, github wikis don't work like this. I do really like the idea of the wiki being backed by a repo rather than some opaque format though. Anyone know of anything like that? We could also look at locking down the wiki to trac account owners only. This should probably be done right now. (I'm not sure how to do it though.) Also, I think much of the wiki content should be moved into the docs instead. - Robert From nikita at nemkin.ru Thu Aug 29 08:24:08 2013 From: nikita at nemkin.ru (Nikita Nemkin) Date: Thu, 29 Aug 2013 12:24:08 +0600 Subject: [Cython] Problem with final cdef methods In-Reply-To: <521ED605.8040005@behnel.de> References: <521ED605.8040005@behnel.de> Message-ID: On Thu, 29 Aug 2013 11:03:01 +0600, Stefan Behnel wrote: > I noticed two problems with final cdef methods. When overriding a normal > cdef method with a final cdef method, you currently get a C compiler > warning about a call with the wrong 'self' type, and when you call them > before you declare them in your code, you get an error because the method > is not forward declared. > > http://trac.cython.org/cython_trac/ticket/819 > > I think this suggests that we should try to come up with a cleaner way to > integrate this feature into the function overloading architecture rather > than just remembering their cname and call that. As your ticket mentions, there is a fundamental problem with method inheritance. (and with the way Cython generates forward declarations...) Any inherited method assumes 2 types simultaneously: the type of the base method with 1st parameter being a base class pointer and the "actual" type of the method with 1st parameter being derived class pointer. 1st type, stored in method's Entry.type, is essentially the vtable slot type. It's used when virtual method calls a made. It's also used for generating forward declarations and for casting in vtable init code. 2nd type (stored in CFuncDef node) is used ONLY to generate function definition. The mismatch between these 2 types is the root of the problem. Before final methods were introduced, the 2nd ("actual") type was unimportant. Method was cast to the vtable slot type in vtable init code and forgotten. But final functions, bypassing vtable mechanic, rely soley on the 2nd type. I have solved it for myself by storing BOTH types in the method entry (Entry.type for the actual CFuncDef type and Entry.prev_type for the vtable slot type). By using correct types in generate_exttype_final_methods_declaration() and generate_exttype_vtable_init_code() the problem is avoided. You can see the patch here https://github.com/nnemkin/cython/compare/final_subtypes Notes for the patch: * I removed a bit of wtf code from CFuncType.declaration_code, these changes are incidental to the problem you describe. (Strictly necessary parts are only the lines involving "prev_type"). * There is a disabled bug test named "inherited_final_method", you may want to remove/merge it with the test you modified. I hope this helps. Best regards, Nikita Nemkin From stefan_ml at behnel.de Thu Aug 29 08:57:19 2013 From: stefan_ml at behnel.de (Stefan Behnel) Date: Thu, 29 Aug 2013 08:57:19 +0200 Subject: [Cython] Problem with final cdef methods In-Reply-To: References: <521ED605.8040005@behnel.de> Message-ID: <521EF0CF.60006@behnel.de> Nikita Nemkin, 29.08.2013 08:24: > On Thu, 29 Aug 2013 11:03:01 +0600, Stefan Behnel wrote: >> http://trac.cython.org/cython_trac/ticket/819 > > As your ticket mentions, there is a fundamental problem with method > inheritance. > (and with the way Cython generates forward declarations...) > > Any inherited method assumes 2 types simultaneously: the type of the base > method with 1st parameter being a base class pointer and the "actual" type > of the method with 1st parameter being derived class pointer. > 1st type, stored in method's Entry.type, is essentially the vtable slot > type. It's used when virtual method calls a made. It's also used for > generating > forward declarations and for casting in vtable init code. > 2nd type (stored in CFuncDef node) is used ONLY to generate function > definition. > > The mismatch between these 2 types is the root of the problem. > Before final methods were introduced, the 2nd ("actual") type was unimportant. > Method was cast to the vtable slot type in vtable init code and forgotten. > But final functions, bypassing vtable mechanic, rely soley on the 2nd type. Thanks for writing up the analysis. > I have solved it for myself by storing BOTH types in the method entry > (Entry.type for the actual CFuncDef type and Entry.prev_type for the vtable > slot type). By using correct types in > generate_exttype_final_methods_declaration() > and generate_exttype_vtable_init_code() the problem is avoided. > You can see the patch here > https://github.com/nnemkin/cython/compare/final_subtypes Interesting. Your change dates back a while already. Were you planning to clean it up in some way before you submit it as pull request? > Notes for the patch: > * I removed a bit of wtf code from CFuncType.declaration_code, I'm not surprised. :) > * There is a disabled bug test named "inherited_final_method", And you had to disable it, because ... ? > you may want to remove/merge it with the test you modified. I already looked at it before I changed the main test. It appears to be a regression test for a specific bug that's different from the problem at hand, that's why I didn't touch it. Stefan From nikita at nemkin.ru Thu Aug 29 09:19:34 2013 From: nikita at nemkin.ru (Nikita Nemkin) Date: Thu, 29 Aug 2013 13:19:34 +0600 Subject: [Cython] Problem with final cdef methods In-Reply-To: <521EF0CF.60006@behnel.de> References: <521ED605.8040005@behnel.de> <521EF0CF.60006@behnel.de> Message-ID: On Thu, 29 Aug 2013 12:57:19 +0600, Stefan Behnel wrote: > Nikita Nemkin, 29.08.2013 08:24: >> I have solved it for myself by storing BOTH types in the method entry >> (Entry.type for the actual CFuncDef type and Entry.prev_type for the >> vtable >> slot type). By using correct types in >> generate_exttype_final_methods_declaration() >> and generate_exttype_vtable_init_code() the problem is avoided. >> You can see the patch here >> https://github.com/nnemkin/cython/compare/final_subtypes > > Interesting. Your change dates back a while already. Were you planning to > clean it up in some way before you submit it as pull request? That was the plan. My solution is kind of stopgap (even the name "prev_type" makes me cringe), but "proper" solution would require some serious redesign and rewrite work, which may be unwise in itsef. So I got stuck and left it behind. If you want the problem fixed with minimal changes to the Cython codebase, you can use my approach. BTW I havent thoroughly tested that patch. It works for me in my environment and passes the test suite, but that's it. >> Notes for the patch: >> * There is a disabled bug test named "inherited_final_method", > > And you had to disable it, because ... ? > >> you may want to remove/merge it with the test you modified. > > I already looked at it before I changed the main test. It appears to be a > regression test for a specific bug that's different from the problem at > hand, that's why I didn't touch it. The test was already disabled, because it hit the open bug. It's the same bug we are talking about: mismatch between Entry.type and the actual method type. Please take a closer look at it. My patch ENABLES the test because it fixes the bug. Best regards, Nikita Nemkin From stefan_ml at behnel.de Thu Aug 29 10:12:39 2013 From: stefan_ml at behnel.de (Stefan Behnel) Date: Thu, 29 Aug 2013 10:12:39 +0200 Subject: [Cython] Problem with final cdef methods In-Reply-To: References: <521ED605.8040005@behnel.de> <521EF0CF.60006@behnel.de> Message-ID: <521F0277.3060407@behnel.de> Nikita Nemkin, 29.08.2013 09:19: > The test was already disabled, because it hit the open bug. > My patch ENABLES the test because it fixes the bug. Sorry, sure. I accidentally read it the other way round. Once the fix is in, I think both tests should just be merged. Stefan From stefan_ml at behnel.de Thu Aug 29 10:24:34 2013 From: stefan_ml at behnel.de (Stefan Behnel) Date: Thu, 29 Aug 2013 10:24:34 +0200 Subject: [Cython] Problem with final cdef methods In-Reply-To: References: <521ED605.8040005@behnel.de> <521EF0CF.60006@behnel.de> Message-ID: <521F0542.3020107@behnel.de> Nikita Nemkin, 29.08.2013 09:19: > On Thu, 29 Aug 2013 12:57:19 +0600, Stefan Behnel wrote: >> Nikita Nemkin, 29.08.2013 08:24: >>> I have solved it for myself by storing BOTH types in the method entry >>> (Entry.type for the actual CFuncDef type and Entry.prev_type for the vtable >>> slot type). By using correct types in >>> generate_exttype_final_methods_declaration() >>> and generate_exttype_vtable_init_code() the problem is avoided. >>> You can see the patch here >>> https://github.com/nnemkin/cython/compare/final_subtypes >> >> Interesting. Your change dates back a while already. Were you planning to >> clean it up in some way before you submit it as pull request? > > That was the plan. > My solution is kind of stopgap (even the name "prev_type" makes me cringe), Yes, not the ideal name. > but "proper" solution would require some serious redesign and rewrite work, > which may be unwise in itsef. So I got stuck and left it behind. > > If you want the problem fixed with minimal changes to the Cython > codebase, you can use my approach. For closures, we use an "outer_entry" that refers to the same variable Entry in the outer scope. We could do something similar for methods, basically a reference to the overridden base type method. To find out the vtable type, you'd go up the Entry hierarchy and look up the type of the original method definition. That could be hidden behind a method or even a property. > BTW I havent thoroughly tested that patch. It works for me > in my environment and passes the test suite, but that's it. As long as it also fixes the test I added, I'm happy. :) I would expect the Sage tests to catch any remaining issues. They are pretty subtype heavy. Stefan From stefan_ml at behnel.de Sat Aug 31 15:28:33 2013 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sat, 31 Aug 2013 15:28:33 +0200 Subject: [Cython] Should we monkey patch inspect.isfunction() ? Message-ID: <5221EF81.2030302@behnel.de> Hi, currently, this fails in Cython compiled code: def cyfunc(): pass import inspect assert inspect.isfunction(cyfunc) There isn't really much of a reason why this *should* fail, except for the implementation of inspect.isfunction(), which tests for isinstance(obj, types.FunctionType) where types.FunctionType is type(some_python_function). In the benchmarks that we run on Jenkins, I'm patching into this as follows: """ def patch_inspect_isfunction(): import inspect orig_isfunction = inspect.isfunction def isfunction(obj): return (orig_isfunction(obj) or type(obj).__name__ == 'cython_function_or_method') isfunction._orig_isfunction = orig_isfunction inspect.isfunction = isfunction patch_inspect_isfunction() """ For example, Django uses inspect.isfunction() in some dynamic code and requires this fix to run properly when compiled. Now that we have a function type that is shared between different Cython modules, I think it's worth considering the addition of a proper type test in the inspect module as a general 'fix'. Meaning that we could patch the inspect module automatically whenever we insert the Cython function type into the shared Cython types module. I'm aware that this is a bit evil and hackish, but it usually works quite nicely. I'm also aware that the proper way to do this would eventually be the ABC mechanism as defined by PEP 3119, but Python's function type doesn't currently support the ABC protocol. We could additionally lobby for getting that changed. http://www.python.org/dev/peps/pep-3119/#overloading-isinstance-and-issubclass Opinions? Stefan From vitja.makarov at gmail.com Sat Aug 31 15:45:05 2013 From: vitja.makarov at gmail.com (Vitja Makarov) Date: Sat, 31 Aug 2013 17:45:05 +0400 Subject: [Cython] Should we monkey patch inspect.isfunction() ? In-Reply-To: <5221EF81.2030302@behnel.de> References: <5221EF81.2030302@behnel.de> Message-ID: 2013/8/31 Stefan Behnel : > Hi, > > currently, this fails in Cython compiled code: > > def cyfunc(): pass > > import inspect > assert inspect.isfunction(cyfunc) > > There isn't really much of a reason why this *should* fail, except for the > implementation of inspect.isfunction(), which tests for > > isinstance(obj, types.FunctionType) > > where types.FunctionType is type(some_python_function). > > In the benchmarks that we run on Jenkins, I'm patching into this as follows: > > """ > def patch_inspect_isfunction(): > import inspect > orig_isfunction = inspect.isfunction > def isfunction(obj): > return (orig_isfunction(obj) > or type(obj).__name__ == 'cython_function_or_method') > isfunction._orig_isfunction = orig_isfunction > inspect.isfunction = isfunction > > patch_inspect_isfunction() > """ > > For example, Django uses inspect.isfunction() in some dynamic code and > requires this fix to run properly when compiled. > > Now that we have a function type that is shared between different Cython > modules, I think it's worth considering the addition of a proper type test > in the inspect module as a general 'fix'. Meaning that we could patch the > inspect module automatically whenever we insert the Cython function type > into the shared Cython types module. > > I'm aware that this is a bit evil and hackish, but it usually works quite > nicely. > > I'm also aware that the proper way to do this would eventually be the ABC > mechanism as defined by PEP 3119, but Python's function type doesn't > currently support the ABC protocol. We could additionally lobby for getting > that changed. > > http://www.python.org/dev/peps/pep-3119/#overloading-isinstance-and-issubclass > > Opinions? > I think we should do something like gevent does: https://github.com/surfly/gevent/blob/master/gevent/monkey.py It allows user to manually apply patch. It would be something like this: import cython cython.patch_all() -- vitja.