Mailman 3 May 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

Exporting inline functions from a pyx.
by Jesus-Omar Ocegueda-Gonzalez May 31, 2015

May 31, 2015

Dear Cython developers, thanks for the awesome compiler!, we recently faced an issue exporting inline functions defined in a .pyx. According to this: http://docs.cython.org/src/tutorial/pxd_files.html the full inline definition (not just the declaration) should be in the pxd. However, if we put the definition in the .pyx and just its declaration header in the .pxd, Cython declares a pointer to the inline function similar to: static CYTHON_INLINE double (*__function_name)(...); /*proto*/ but this causes a compilation error in some platforms (but successfully compiles in others) because variables cannot be declare as inline. You can find a log with the compilation errors here: http://nipy.bic.berkeley.edu/builders/dipy-py2.7-osx-10.8/builds/362/steps/… I guess it should be possible to detect when a function is inline and in that case remove the CYTHON_INLINE from the pointer declaration, or at least consistently fail in all platforms. Is this a known issue? Thank you very much! With warm regards, -Omar. -- "Cada quien es dueño de lo que calla y esclavo de lo que dice" -Proverbio chino. "We all are owners of what we keep silent and slaves of what we say" -Chinese proverb. http://www.cimat.mx/~omar

3 4

PEP 492 implemented (async/await)
by Stefan Behnel May 30, 2015

May 30, 2015

Hi, I invested a couple of days implementing PEP 492 in Cython. https://www.python.org/dev/peps/pep-0492/ It turned out nicely, so it's now merged into master to become part of Cython 0.23. I also spent some time testing and debugging it against Python 3.5 so that Yury Selivanov could adapt their side for interoperability. The second beta of 3.5 will be released tomorrow and it should "just work". Testing is very welcome. Note that the language feature is available in Cython for all Python versions (2.6+), but usage from Python code with async/await is obviously limited to Python 3.5 where this syntax is available. My guess is that one of the next asyncio (and trollius) backport package releases will add support as well, so that you could run Cython coroutines on top of asyncio also in older Python releases. It's mostly about dropping some explicit type checks here and there or replacing them with ABC isinstance checks. Have fun, Stefan

1 0

Broken link to CEP 516
by Jeroen Demeyer May 24, 2015

May 24, 2015

At http://docs.cython.org/src/reference/compilation.html#compiler-directives there are two links to "CEP 516" but they are broken. Jeroen.

5 4

a C++ wrapping wishlist
by Stefan Behnel May 24, 2015

May 24, 2015

Someone wrote a list of shortcomings after wrapping some C++ code: http://blog.marcus-brinkmann.de/2014/07/31/cython-trouble/ A couple of these issues are due to misunderstandings (specifically the "imports" section) or now-fixed bugs (post is almost a year old), but it seems that some of them are still valid and might be low-hanging fruit. Stefan

3 2

Pull request #374 (api mangling prefix) merged in Sage
by Jeroen Demeyer May 23, 2015

May 23, 2015

This has been merged in Sage's version of Cython: https://github.com/cython/cython/pull/374 The change looks quite innocent, so I so little reason to not merge it in Cython master.

1 0

Cython generates invalid C code for some generator expressions in cdef functions
by Michael Enßlin May 21, 2015

May 21, 2015

Take the following example: $ cat t2.pyx cdef void read_callback(): foo = b"asdf" bar = (c for c in foo) $ cython t2.pyx $ gcc -I/usr/include/python3.4m t2.c t2.c: In function ‘__pyx_f_2t2_read_callback’: t2.c:778:12: error: ‘None’ undeclared (first use in this function) return None; ^ t2.c:778:12: note: each undeclared identifier is reported only once for each function it appears in t2.c:778:5: warning: ‘return’ with a value, in function returning void return None; ^ Note that the error does not occur for bar = (c for c in b"asdf") or bar = [c for c in b"asdf"] ~ mic_e

2 1

Misleading error message when assigning function pointers with differing except* declarations
by Michael Enßlin May 21, 2015

May 21, 2015

Hi, consider the following example: $ cat demo.pyx cdef void (*foo)() cdef void bar() except*: pass foo = bar $ cython demo.pyx Error compiling Cython file: ------------------------------------------------------------ ... cdef void (*foo)() cdef void bar() except*: pass foo = bar ^ ------------------------------------------------------------ demo.pyx:6:9: Cannot assign type 'void (void)' to 'void (*)(void)' this is all expected behavior, but the error message is entirely misleading; it should be something like demo.pyx:6:9: Function pointers have incompatible 'except *' declarations. Note that the same error message also occurs when the pointer is declared except*, and the function isn't. ~ mic_e

2 1

PEP 448 implemented: unpacking generalisations
by Stefan Behnel May 15, 2015

May 15, 2015

Hi, I implemented PEP 448 in the latest master branch. It extends Python's unpacking syntax to allow things like d = {**kw, 1: 2, 3: 4, **morekw} s = {1, 2, 3, *args, *extra} t = (1, *x, *y, *z) head, *tail = [*x, *y] func(**kw1, **kw2) https://www.python.org/dev/peps/pep-0448/ For function calls, you'll get an error for duplicate keys, but not for dicts and sets, where the last entry prevails. I'd be happy to see some feedback. The code it generates is already pretty good and I've added a whole bunch of tests, but it definitely needs some user side testing. If you find anything that doesn't work, please send a pull request that adds a test to one of the pep448_*.pyx test files in the tests directory. Stefan

1 0