[Cython] Cython 0.23 beta 1 released

2015-07-20 Thread Stefan Behnel
Hi everyone,

I just uploaded a first beta for the upcoming Cython 0.23. There have
been many major changes and fixes, so please give it some testing with
your own code - especially on less commonly tested platforms, namely MS
Windows.

You can get the signed release from here:

http://cython.org/release/

http://cython.org/release/Cython-0.23.beta1.tar.gz

http://cython.org/release/Cython-0.23.beta1.zip

SHA1 sums:
45347674bf14ebfce879dd1bf15af64387a39f8c  Cython-0.23.beta1.tar.gz
0db13cdd8a11f83158e5c72f5e84b89e574af215  Cython-0.23.beta1.zip

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.

Note that the coverage analysis support is still incomplete as the plugin
API of the coverage.py tool itself is still subject to modifications.

Have fun,

Stefan



Changelog:
==

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.

* ``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.

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/issue23996

* Language level 3 did not enable true division (a.k.a. float division)
  for integer operands.

* Functions with fused argument types that included a generic 'object'
  fallback could end up using that fallback also for other explicitly
  listed object types.

* Relative cimports could accidentally fall back to trying an absolute
  cimport on failure.

* The result of calling a C struct constructor no longer requires an
  intermediate assignment when coercing to a Python dict.

* C++ exception declarations with mapping functions could fail to compile
  when pre-declared in .pxd files.

* ``cpdef void`` methods are now permitted.

* ``abs(cint)`` could fail to compile in MSVC and used sub-optimal code
  in C++.  Patch by David Vierra, original patch by Michael Enßlin.

* Buffer index calculations using index variables with small C integer
  types could overflow for large buffer sizes.
  Original patch by David Vierra.

* C unions use a saner way to coerce from and to P

Re: [Cython] Cython 0.23 beta 1 released

2015-07-20 Thread Jeroen Demeyer

Hello,

The changelog should mention something about the very recent changes to 
"enum". Some bad code in Sage (a literal integer pretending to be an 
enum) needed to be fixed because of this change.


Jeroen.
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel


[Cython] Non-type template parameters

2015-07-20 Thread Ian Henriksen
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?

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.

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