[Cython] Cython 0.23 beta 2 released
Hi everyone, I just uploaded a second beta for the upcoming Cython 0.23. Please give it some more testing as there were substantial code changes since the first beta. You can get the signed release from here: http://cython.org/release/ http://cython.org/release/Cython-0.23b2.tar.gz http://cython.org/release/Cython-0.23b2.zip SHA1 sums: 1d12e335116ba3fcbe731d83ccc5ee5f0f6e5371 Cython-0.23b2.tar.gz 6f063e6b08b6dbecbadd44ed6c6150bc799fa230 Cython-0.23b2.zip Changes since beta 1 (in addition to general bug fixes): * The builtin ``type`` type is now declared as PyTypeObject in source, allowing for extern functions taking type parameters to have the correct C signatures. Note that this might break code that uses ``type`` just for passing around Python types in typed variables. Removing the type declaration provides a backwards compatible fix. * Support operator bool() for C++ classes so they can be used in if statements. * Installation under CPython 3.3+ no longer requires a pass of the 2to3 tool. This also makes it possible to run Cython in Python 3.3+ from a source checkout without installing it first. Patch by Petr Viktorin. * Coverage analysis and async/await were adapted to recent changes in coverage.py and CPython. Complete changelog follows below. Since we're in beta phase now, new features should not generally be added for the release any more, but we can make exceptions for currently existing pull requests if you can provide a good motivation. If you think we forgot something, sending a timely reply to this email or reviving an existing mailing list thread or pull request is a good idea. Have fun, Stefan Features added -- * PEP 492 (async/await) was implemented. See https://www.python.org/dev/peps/pep-0492/ * PEP 448 (Additional Unpacking Generalizations) was implemented. See https://www.python.org/dev/peps/pep-0448/ * Support for coverage.py 4.0+ can be enabled by adding the plugin "Cython.Coverage" to the ".coveragerc" config file. * Annotated HTML source pages can integrate (XML) coverage reports. * Tracing is supported in ``nogil`` functions/sections and module init code. * When generators are used in a Cython module and the module imports the modules "inspect" and/or "asyncio", Cython enables interoperability by patching these modules during the import to recognise Cython's internal generator and coroutine types. This can be disabled by C compiling the module with "-D CYTHON_PATCH_ASYNCIO=0" or "-D CYTHON_PATCH_INSPECT=0" * When generators or coroutines are used in a Cython module, their types are registered with the ``Generator`` and ``Coroutine`` ABCs in the ``collections`` or ``collections.abc`` stdlib module at import time to enable interoperability with code that needs to detect and process Python generators/coroutines. These ABCs were added in CPython 3.5 and are available for older Python versions through the ``backports_abc`` module on PyPI. See https://bugs.python.org/issue24018 * Adding/subtracting/dividing/modulus and equality comparisons with constant Python floats and small integers are faster. * Binary and/or/xor/rshift operations with small constant Python integers are faster. * When called on generator expressions, the builtins ``all()``, ``any()``, ``dict()``, ``list()``, ``set()``, ``sorted()`` and ``unicode.join()`` avoid the generator iteration overhead by inlining a part of their functionality into the for-loop. * Keyword argument dicts are no longer copied on function entry when they are not being used or only passed through to other function calls (e.g. in wrapper functions). * The ``PyTypeObject`` declaration in ``cpython.object`` was extended. * The builtin ``type`` type is now declared as PyTypeObject in source, allowing for extern functions taking type parameters to have the correct C signatures. Note that this might break code that uses ``type`` just for passing around Python types in typed variables. Removing the type declaration provides a backwards compatible fix. * ``wraparound()`` and ``boundscheck()`` are available as no-ops in pure Python mode. * Const iterators were added to the provided C++ STL declarations. * ``NULL`` is allowed as default argument when embedding signatures. This fixes ticket 843. * When compiling with ``--embed``, the internal module name is changed to ``__main__`` to allow arbitrary program names, including those that would be invalid for modules. Note that this prevents reuse of the generated C code as an importable module. * External C++ classes that overload the assignment operator can be used. Patch by Ian Henriksen. * Support operator bool() for C++ classes so they can be used in if statements. Bugs fixed -- * Calling "yield from" from Python on a Cython generator that returned a value triggered a crash in CPython. This is now being worked around. See https://bugs.python.org/issue2399
Re: [Cython] Non-type template parameters
On Tue, Jul 28, 2015 at 12:37 PM Robert Bradshaw wrote: > On Tue, Jul 28, 2015 at 11:18 AM, Ian Henriksen > wrote: > > > > On Tue, Jul 28, 2015 at 1:36 AM Robert Bradshaw > wrote: > >> > >> Sorry for not getting back sooner... responses below. > >> > >> On Mon, Jul 20, 2015 at 2:06 PM, Ian Henriksen > >> wrote: > >> > Hi all, > >> > I've spent a little time working on adding support for non-type > >> > template parameters. In doing this, it has been very easy to add > >> > support for doing something like the following: > >> > > >> > cdef extern from "add_const.hpp" nogil: > >> > int myfunc1[i](int) > >> > def test(): > >> > print myfunc1[2](a) > >> > > >> > The downside of this is that it does not let the Cython compiler > >> > distinguish between different kinds of template parameters. > >> > > >> > Stricter checking could be added using a syntax like this: > >> > > >> > cdef extern from "add_const.hpp" nogil: > >> > int myfunc1[int i](int) > >> > def test(): > >> > print myfunc1[2](a) > >> > > >> > The downsides here are that the syntax doesn't really match the > >> > existing template syntax. It will also complicate the Cython codebase > >> > since we'll have to go to greater lengths to allow or disallow all the > >> > different special cases for templates. > >> > > >> > Which version would be preferable? > >> > >> I think I'd prefer the [int i] syntax. Hopefully it shouldn't > >> complicate things too much. > > > > Okay, I think I see a way to make that work. On the other hand, since > there > > weren't any replies here, I've already nearly finished implementing the > > first > > syntax. I'll spend another hour or two finishing it off later today and > > submit a PR > > so you can look it over. I originally favored the first syntax because it > > minimizes > > the number of fancy template features (SFINAE, for example) we have to > worry > > about on the Cython end. I'm still open to discuss it though. > > I think this falls into the "explicit is better than implicit" bucket. > That and getting obscure template errors that could have been caught > at Cython compile time will be very nice. > > >> > On a similar note, for variadic templates, would we prefer something > >> > like > >> > > >> > cdef extern from "my_variadic.hpp" nogil: > >> > T myfunc2[T,...](T, ...) > >> > > >> > or something like: > >> > > >> > cdef extern from "my_variadic.hpp" nogil: > >> > T myfunc2[T, Types...](T, Types... args) > >> > > >> > Again, the latter syntax is more explicit, but it will require much > more > >> > complicated code in Cython. It also doesn't match the existing syntax > >> > very well. The former syntax matches the existing syntax for templates > >> > better, but will make it hard for Cython to raise errors early on in > >> > compilation. > >> > >> Hmm... this is a tougher call. Let's go with the former for now. > > > > > > I like the former a lot more. It will keep the syntax simpler on our end > and > > I > > haven't been able to find any case that it doesn't cover. This will also > be > > significantly easier to implement. I'll take a look at it soon. > > Sounds good. > > There's also the question of default arguments. Let's adopt the [type > T = *] syntax for that. > > >> > I'd greatly appreciate any input on the best syntax for either > use-case. > >> > > >> > Regards, > >> > > >> > -Ian Henriksen > >> > > >> > ___ > >> > cython-devel mailing list > >> > cython-devel@python.org > >> > https://mail.python.org/mailman/listinfo/cython-devel > >> > > >> ___ > >> cython-devel mailing list > >> cython-devel@python.org > >> https://mail.python.org/mailman/listinfo/cython-devel > > > > > > ___ > > cython-devel mailing list > > cython-devel@python.org > > https://mail.python.org/mailman/listinfo/cython-devel > > > ___ > cython-devel mailing list > cython-devel@python.org > https://mail.python.org/mailman/listinfo/cython-devel Yep, I can see why that syntax makes sense. I'm a little worried I may not be able to finish adding all of this in the near future. Adding all the of this type checking for templates goes a long way toward implementing the full syntax for declaring them. That said, it seems sensible to catch errors early if possible. Thanks! -Ian Henriksen ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
