Mailman 3 April 2015 - cython-devel

[RFE] Add dummy compiler directive decorators for pure python mode
by Carlos Pita July 28, 2015

July 28, 2015

Hi all, pure python mode will benefit from the addition of dummy decorators for compiler directives to Shadow.py, like in: @cython.boundscheck(False) def f(): pass AFAICS this is not currently valid inside the interpreter. Cheers -- Carlos

3 5

Re: [Cython] operator() bug in cython
by Ulrich Dobramysl June 23, 2015

June 23, 2015

On Fri Feb 13 2015 at 11:07:39 PM Greg Ewing <greg.ewing(a)canterbury.ac.nz> wrote: > Ulrich Dobramysl wrote: > > > Thanks! I haven't figured out how to call heap allocated objects, as the > > code > > --- > > cdef OperatorTest *t = new OperatorTest() > > t() > > --- > > is not translatable by Cython. > > Have you tried: > > t[0]() > > ? > Thanks, I didn't think about the t[0] trick! > I haven't been following the development of Cython's internals, > so I may be speaking naively here, but it looks wrong to me that > the cname of that entry should be 'operator()' rather than the > c-level name of the variable that the NameNode refers to. > > The cname of the entry is correct IMO, because it cannot have any knowledge about the cname of the object it is being called as later. The logic dealing with the special case of an operator() member function of a c++ class in SimpleCallNode.analyse_c_function_call() needs to be changed slightly to not treat operator() as an overloaded entry. Rather, the function type of the SimpleCallNode needs to be set to the type of the looked-up operator() entry. Then, at the code generation stage, the correct cname of the SimpleCallNode entry is used and not the entry of operator(). With the patch below my test case compiles and runs without problems: ---- diff --git a/Cython/Compiler/ExprNodes.py b/Cython/Compiler/ExprNodes.py index f99ec6e..88522c9 100644 --- a/Cython/Compiler/ExprNodes.py +++ b/Cython/Compiler/ExprNodes.py @@ -4569,11 +4569,13 @@ class SimpleCallNode(CallNode): args = self.args if func_type.is_cpp_class: - overloaded_entry = self.function.type.scope.lookup("operator()") - if overloaded_entry is None: + call_operator = self.function.type.scope.lookup("operator()") + if call_operator is None: self.type = PyrexTypes.error_type self.result_code = "<error>" return + self.function.type = call_operator.type + overloaded_entry = None elif hasattr(self.function, 'entry'): overloaded_entry = self.function.entry elif (isinstance(self.function, IndexNode) and @@ -4603,7 +4605,7 @@ class SimpleCallNode(CallNode): else: entry = None func_type = self.function_type() - if not func_type.is_cfunction: + if not (func_type.is_cfunction or func_type.is_cpp_class): error(self.pos, "Calling non-function type '%s'" % func_type) self.type = PyrexTypes.error_type self.result_code = "<error>" ---- What do you think? I don't know a lot about cython's internals, so there might be use cases which break this code. Ulrich

2 2

[PATCH 1/2] Move ~/.pyxbld to $XDG_CACHE_HOME/pyxbld
by Emmanuel Gil Peyrot April 29, 2015

April 29, 2015

--- pyximport/pyximport.py | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/pyximport/pyximport.py b/pyximport/pyximport.py index 4fd7fe9..710c5eb 100644 --- a/pyximport/pyximport.py +++ b/pyximport/pyximport.py @@ -466,9 +466,10 @@ def install(pyximport=True, pyimport=False, build_dir=None, build_in_temp=True, will not work for most .py files, and will therefore only slow down your imports. Use at your own risk. - By default, compiled modules will end up in a ``.pyxbld`` - directory in the user's home directory. Passing a different path - as ``build_dir`` will override this. + By default, compiled modules will end up in a ``pyxbld`` directory + in the directory pointed by the ``XDG_CACHE_HOME`` environment + variable, or in ``~/.cache/pyxbld`` if ``XDG_CACHE_HOME`` isn’t + set. Passing a different path as ``build_dir`` will override this. ``build_in_temp=False`` will produce the C files locally. Working with complex dependencies and debugging becomes more easy. This @@ -501,8 +502,9 @@ def install(pyximport=True, pyimport=False, build_dir=None, build_in_temp=True, runtime for .py files and Py2 for .pyx files. """ if not build_dir: - build_dir = os.path.join(os.path.expanduser('~'), '.pyxbld') - + build_dir = os.path.join(os.environ.get('XDG_CACHE_HOME', + os.path.join(os.path.expanduser('~'), '.cache')), 'pyxbld') + global pyxargs pyxargs = PyxArgs() #$pycheck_no pyxargs.build_dir = build_dir -- 2.3.5

1 2

New hosting
by Robert Bradshaw April 28, 2015

April 28, 2015

Since Cython's inception, we've been able to take advantage of William Stein's and University of Washington's infrastructure for hosting the Cython project along side that of Sage. However, due to UW policy, those days are coming to and end. Maybe it's time--Cython has come a long way from its birth of SageX + lxml. So the question is where to move. Our primary needs are not that large: we've got a site, a bugtracker (trac), and a continuous build (jenkins) currently being served (the source code and wiki have already been migrated to github). I would propose that we look into moving everything we can over to github. For starters, they now offer serving simple sites from a repository (cython.org) so that seems an obvious choice. I know their bug tracking v1 was considered far inferior to trac, but the situation may be better now (at least worth exploring). We also have travis.ci, which isn't as configurable as jenkins, but may be good enough. (The biggest deficiency is that it probably wouldn't allow for building and testing Sage regularly, or benchmarks, this is the one thing that we may need to find/provide custom hosting for.) Thoughts?

3 3

Dash in the executable's filename
by Anton D. Kachalov April 27, 2015

April 27, 2015

4 5

release preparations for 0.22.1 and 0.23
by Stefan Behnel April 26, 2015

April 26, 2015

Hi, I think it's about time for a new release. I propose to relase 0.22.1 in the next days, and then start the release cycle for 0.23. Please make sure everything that you consider a safe bug fix is in the 0.22.x branch. I already copied Jeroen's latest fixes over. Stefan

2 2

Cython produces invalid C code
by Michael Enßlin April 23, 2015

April 23, 2015

Hi everybody, Cython 0.21.1, from Debian Sid, and Cython 0.22, from Gentoo, produce invalid C Code for the following .pyx file: $ cat test.pyx cimport cpython cdef extern from "test.h": cdef void foo(int i = 0) def bar(self): foo(0) $ cat test.h void foo(int i); $ cython test.pyx $ gcc -c test.c -I/usr/include/python3.4m test.c: In function ‘__pyx_pf_4test_bar’: test.c:659:35: error: storage size of ‘__pyx_t_1’ isn’t known struct __pyx_opt_args_4test_foo __pyx_t_1; $ clang test.c -I/usr/include/python3.4m test.c:659:35: error: variable has incomplete type 'struct __pyx_opt_args_4test_foo' struct __pyx_opt_args_4test_foo __pyx_t_1; test.c:659:10: note: forward declaration of 'struct __pyx_opt_args_4test_foo' struct __pyx_opt_args_4test_foo __pyx_t_1; Note that this is a minimal example; removing anything from test.pyx fixes the issue (the 'cimport' statement, the default value for int i, and the call to foo). The issue also occurs with --cplus. Happy debugging, mic_e

2 2

Generator ABC in Py3.5
by Stefan Behnel April 21, 2015

April 21, 2015

Hi, I'm currently working on making the Generator protocol an ABC in Python 3.5. That will allow Cython generators to finally stand en-par with Python generators. https://bugs.python.org/issue24018 Stefan

1 0

PEP 492 - Coroutines with async and await syntax
by Stefan Behnel April 18, 2015

April 18, 2015

Hi! Looks like there's a new PEP coming up which receives rather strong support: https://www.python.org/dev/peps/pep-0492/ It proposes new sytax constructs like async with EXPR as VAR: BLOCK async for TARGET in ITER: BLOCK that substantially simplify asynchronous code. Here's the current discussion thread on python-ideas: http://comments.gmane.org/gmane.comp.python.ideas/33009 Stefan

1 0

PEP 489: Redesigning extension module loading
by Stefan Behnel April 17, 2015

April 17, 2015

Hi, I've been involved in redesigning a new protocol for importing extension modules, which might make it into CPython 3.5. I think it's now ready for general consideration. http://article.gmane.org/gmane.comp.python.import/508 It solves several issues with the current scheme and brings it much closer to the behaviour of "normal" Python modules. Stefan

1 0