[Cython] Cython 0.27 beta 1 is available
Right, I forgot that alpha releases always scream for not being touched. ;) So here's the same thing as beta-1 to get things rolling. https://github.com/cython/cython/archive/0.27b1.tar.gz Changelog: https://github.com/cython/cython/blob/2c9641a749208dbc405209e367b8a23e1310564d/CHANGES.rst Feedback is appreciated. Stefan Stefan Behnel schrieb am 16.09.2017 um 11:39: > 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/2c9641a749208dbc405209e367b8a23e1310564d/CHANGES.rst > > 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 ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [cython-users] Cython 0.27 beta 1 is available
> On Sep 19, 2017, at 02:49, Stefan Behnel wrote: > > Right, I forgot that alpha releases always scream for not being touched. ;) > > So here's the same thing as beta-1 to get things rolling. > > https://github.com/cython/cython/archive/0.27b1.tar.gz > > Changelog: > https://github.com/cython/cython/blob/2c9641a749208dbc405209e367b8a23e1310564d/CHANGES.rst > > Feedback is appreciated. gevent doesn't use any of the new features, but I can confirm that it does build and pass its tests under Python 2.7/3.4/3.6 with Cython 0.27b1. Jason ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.27 alpha 1 is available
Regarding Changelog item * gdb support for Python code (libpython.py) was updated to the latest version in CPython 3.7 (git rev 5fe59f8). Does that fix https://github.com/cython/cython/issues/1655 ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.27 alpha 1 is available
Jeroen Demeyer schrieb am 19.09.2017 um 15:05: > Regarding Changelog item > * gdb support for Python code (libpython.py) was updated to the latest > version in CPython 3.7 (git rev 5fe59f8). > > Does that fix https://github.com/cython/cython/issues/1655 I would guess so. The version shipped with CPython is meant to work across different CPython releases, and was definitely adapted to Py3. Stefan ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[Cython] Big backwards compatibility problem with fused types
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 ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Big backwards compatibility problem with fused types
On Tue, Sep 19, 2017 at 10:48 AM, Stefan Behnel wrote: > 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? +1. We should let the .pxd file, as it is declared, be the source of truth. Code that doesn't already follow this is and does cross-module fused-cdef function calls is already broken. ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
