Mailman 3 September 2017 - cython-devel

Website still mentions Python 3.2
by Jeroen Demeyer Sept. 28, 2017

Sept. 28, 2017

I think that this sentence on cython.org is outdated: The C code is generated once and then compiles with all major C/C++ compilers in CPython 2.6, 2.7 (2.4+ with Cython 0.20.x) as well as 3.2 and all later versions.

2 1

Issue with function annotations
by Lisandro Dalcin Sept. 28, 2017

Sept. 28, 2017

$ cython --version Cython version 0.27 $ cat tmp.pyx def f() -> (list, list): return [], [] $ cython tmp.pyx Error compiling Cython file: ------------------------------------------------------------ ... def f() -> (list, list): ^ ------------------------------------------------------------ tmp.pyx:1:12: C struct/union member cannot be a Python object Error compiling Cython file: ------------------------------------------------------------ ... def f() -> (list, list): ^ ------------------------------------------------------------ tmp.pyx:1:12: C struct/union member cannot be a Python object -- Lisandro Dalcin ============ Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Extreme Computing Research Center (ECRC) King Abdullah University of Science and Technology (KAUST) http://ecrc.kaust.edu.sa/ 4700 King Abdullah University of Science and Technology al-Khawarizmi Bldg (Bldg 1), Office # 0109 Thuwal 23955-6900, Kingdom of Saudi Arabia http://www.kaust.edu.sa Office Phone: +966 12 808-0459

2 4

0.27.1 beta
by Stefan Behnel Sept. 27, 2017

Sept. 27, 2017

Hi all, the new features in 0.27 introduced a couple of regressions that Robert and I have been hunting down during the last days. Thanks everyone for reporting bugs and helping to isolate them. I will release a bug fix version this weekend, so here is a beta to see if we caught everything - or broke something new. :) https://github.com/cython/cython/archive/0.27.1b1.tar.gz Changelog: https://github.com/cython/cython/blob/0.27.1b1/CHANGES.rst Please give it some testing. Thanks, Stefan

1 0

Python callable staticmethods?
by John Ehresman Sept. 26, 2017

Sept. 26, 2017

Hi, Is there a way to define a Python callable staticmethod in a Cython cdef class? If not, how hard might this be implement? Thanks, John

3 3

Cython 0.27 released
by Stefan Behnel Sept. 23, 2017

Sept. 23, 2017

Hi all, Cython 0.27 is finally out, with several fixes even since the release candidate. This is a major feature release that implements most of the new functionality in Python 3.6, as well as some long awaited Cython language features. https://pypi.python.org/pypi/Cython These are the major new features: - PEP 484/526 annotation typing - PEP 525/530 async generators - automatic "__richcmp__()" generation from "__eq__()" & friends - support for Python object references in C++ classes - PGO compilation mode in Jupyter notebooks Plus many little enhancements and bug fixes. For a longer list of improvements, see the changelog: https://github.com/cython/cython/blob/0.27/CHANGES.rst Hope you like it. Stefan

1 0

Big backwards compatibility problem with fused types
by Stefan Behnel Sept. 20, 2017

Sept. 20, 2017

Hi devs, this is really bad: https://github.com/cython/cython/pull/1873 The problem is that cdef functions with fused types are expanded arbitrarily on use, and their Entries removed and re-appended to the list of cdef function entries. But that list also defines the order of the entries in the vtable! Currently, when a method with fused types is defined in a .pxd file, it is the implementation order in the .pyx (!) file that determines the order in the vtable. Even worse, for modules that cimport from that .pxd file, it is the order in which these methods are *called* that determines the corresponding vtable on the other side, as the entries are expanded at first use, i.e. at their first occurrence in the code, and appended to the current list of cdef functions at this (arbitrary) point. What this means is that there is no way to safely infer the vtable order of an extension type with fused methods from a .pxd file. Now, the correct way to handle this would have been to *replace* the original fused entry with the expanded list of specialised entries. But it's too late for that now. All existing modules out there would need to get recompiled if we changed their vtable order, at least if they use fused any types methods anywhere in their hierarchy. However, I think we can assume code that uses a different method order in the .pxd and .pyx files to be broken already, so a way out of this misery would be to make the .pxd order the one and only source, with the twist that we must keep the "delete and re-append" algorithm to keep the order that existing translated modules are using. Thus the proposal: - we switch to a scheme now that is only defined by the first declaration order, i.e. the order in the .pxd file if there is one. - we make sure all fused methods are expanded in that same order, but continue to follow all non-fused methods in the vtable. - we break all code now that uses a different order of fused methods in their pyx and pxd files Thoughts? Stefan

2 2

Cython 0.27 alpha 1 is available
by Stefan Behnel Sept. 19, 2017

Sept. 19, 2017

Hi all, Cython 0.27 is nearing completion, so here's an alpha release to get feedback on the many new feature that went in. https://github.com/cython/cython/archive/0.27a1.tar.gz These are the major new features: - PEP 484/526 annotation typing - PEP 525/530 async generators - automatic "__richcmp__()" generation from "__eq__()" & friends - support for Python object references in C++ classes - PGO compilation mode in Jupyter notebooks Plus many little enhancements and bug fixes. For a longer list of improvements, see the changelog: https://github.com/cython/cython/blob/2c9641a749208dbc405209e367b8a23e13105… Hope you like it. The timeframe for the final release is hopefully early October. The more feedback we get, the quicker we can prepare it. Stefan

3 4

Preparing 0.27
by Stefan Behnel Sept. 13, 2017

Sept. 13, 2017

Hi! Current master is starting to feel feature complete for 0.27. If nothing else is pending, I'll prepare an alpha this weekend to collect some feedback on the changes we made. Stefan

1 0

Safer default exception handling with return type annotations?
by Stefan Behnel Sept. 10, 2017

Sept. 10, 2017

Hi all, since PEP 484 type annotations are scheduled for the next release now, I wonder if we should take the opportunity to change the defaults for the exception handling of typed cdef functions. Currently, if you define a function like this: cdef int func(): raise ValueError() It will not actually raise the error but print and ignore it. In order to make it safe, you have to say cdef int func() except -1: raise ValueError() It has always been like this, but with PEP 484 type annotations, it becomes much nicer to keep Cython code Python compatible and actually running in Python, so that the following is safe when interpreted but not when compiled: @cython.cfunc def func(x: cython.int) -> cython.int: if x < 0: raise ValueError() return x * 2 Since this is new syntax, and no code exists yet that uses it, it would be safe to change the default here, and to automatically declare this function as "except? -MIN_INT", for example. The same applies to functions returning pointers ("except? NULL") or even structs, which could be declared "except *". This would lead to inconsistencies within Cython, but I think the use case of Python compatible behaviour is important enough to consider this, and for code using this syntax, it also feels less likely that the caller is actual C code that couldn't handle that exception. Opinions? Stefan

2 7

Error handling during buffer reassignment
by Stefan Behnel Sept. 9, 2017

Sept. 9, 2017

Hi, consider this code: cdef np.ndarray[int32, ndim=1] a a = new_int32_buffer() a = new_float32_buffer() This fails during the second assignment, but only during validation, after unpacking the buffer. The code that handles this case is generated here: https://github.com/cython/cython/blob/c95ca9f21a3524718a83c3415bb7102a50815… Note the twist where it says: # If acquisition failed, attempt to reacquire the old buffer # before raising the exception. I faintly remember a discussion about that case (apparently back in 2008), but can't find it in my mail archive. Might have been off-list at the time. Question: Instead of re-acquiring the buffer (and thus faking the non-assignment), wouldn't it be better to acquire the new buffer in a temp, and only overwrite the old "Py_buffer" if all is fine with it? Stefan

2 2