From jdemeyer at cage.ugent.be  Wed Aug  5 19:25:16 2015
From: jdemeyer at cage.ugent.be (Jeroen Demeyer)
Date: Wed, 05 Aug 2015 18:25:16 +0100
Subject: [Cython] Cython 0.23 beta 2 released
In-Reply-To: <55B91551.5000504@behnel.de>
References: <55B91551.5000504@behnel.de>
Message-ID: <55C246FC.4050101@cage.ugent.be>

As I already mentioned, I still think that the changelog should mention 
something about the changes to "enum". There were 2 threads on the 
mailing list about problems due to this change (code which abused enum 
no longer compiled), so it would be nice to say something about this.

Jeroen.

From robertwb at gmail.com  Thu Aug  6 22:46:36 2015
From: robertwb at gmail.com (Robert Bradshaw)
Date: Thu, 6 Aug 2015 13:46:36 -0700
Subject: [Cython] Cython 0.23 beta 2 released
In-Reply-To: <55C246FC.4050101@cage.ugent.be>
References: <55B91551.5000504@behnel.de> <55C246FC.4050101@cage.ugent.be>
Message-ID: <CADiQ+QAMw3cmLiwG+BRjTivsqjmnuqE-8OKC=u4nJvesk2JGhQ@mail.gmail.com>

On Wed, Aug 5, 2015 at 10:25 AM, Jeroen Demeyer <jdemeyer at cage.ugent.be> wrote:
> As I already mentioned, I still think that the changelog should mention
> something about the changes to "enum". There were 2 threads on the mailing
> list about problems due to this change (code which abused enum no longer
> compiled), so it would be nice to say something about this.

Done.

I also created a new 0.23.x release branch so that development can
continue on master without impacting the release.

FYI, the beta looks good to go for me.

- Robert

From stefan_ml at behnel.de  Sat Aug  8 20:47:48 2015
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sat, 08 Aug 2015 20:47:48 +0200
Subject: [Cython] Cython 0.23 released
Message-ID: <55C64ED4.7050302@behnel.de>

Hi everyone,

given the positive feedback on the previous beta releases, I'm happy to
announce the final release of Cython 0.23. There were only minor changes
and fixes since the second beta.

https://pypi.python.org/pypi/Cython/0.23

This is a major feature release. Highlights include, in addition to several
important bug fixes:

  * PEP 492 (async/await) and PEP 448 (star-unpacking generalizations)
  * inlined generator expressions
  * support for the C++ assignment and bool() operators
  * support for coverage analysis

Complete changelog follows below. Upgrading is generally recommended.


You can get the signed release from here:

http://cython.org/

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

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


SHA1 sums:
5a49123b39d89a20fb88bdc7886210c39cdff695  Cython-0.23.tar.gz
9bec6c6df861be49ed608a0ab688b67bba543abe  Cython-0.23.zip

Have fun,

Stefan



0.23 (2015-08-08)
=================

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.

* Smart pointers were added to the provided C++ STL declarations.
  Patch by Daniel Filonik.

* ``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/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 Python dicts.

* When compiling a module ``foo.pyx``, the directories in ``sys.path``
  are no longer searched when looking for ``foo.pxd``.
  Patch by Jeroen Demeyer.

* Memory leaks in the embedding main function were fixed.
  Original patch by Michael En?lin.

* Some complex Python expressions could fail to compile inside of finally
  clauses.

* Unprefixed 'str' literals were not supported as C varargs arguments.

* Fixed type errors in conversion enum types to/from Python.  Note that
  this imposes stricter correctness requirements on enum declarations.

Other changes
-------------

* Changed mangling scheme in header files generated by ``cdef api``
  declarations.

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

* ``jedi-typer.py`` (in ``Tools/``) was extended and renamed to
  ``jedityper.py`` (to make it importable) and now works with and
  requires Jedi 0.9.  Patch by Tzer-jen Wei.

From antoine at nagafix.co.uk  Sun Aug  9 08:54:49 2015
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Sun, 9 Aug 2015 13:54:49 +0700
Subject: [Cython] Cython 0.23 released
In-Reply-To: <55C64ED4.7050302@behnel.de>
References: <55C64ED4.7050302@behnel.de>
Message-ID: <55C6F939.1040501@nagafix.co.uk>

Hi,

I've just hit a regression with 0.23: a recursion loop generating code
for this particular pyx:
http://xpra.org/trac/browser/xpra/trunk/src/xpra/codecs/nvenc4/encoder.pyx

I don't think we have such loops in our setup.py data structures or in
that pyx, but that's possible. (I will try to check later)
The same code builds fine on all platforms with Cython 0.22.1.

Full stack trace attached to this email. Loop excerpt:
  File "Cython/Compiler/FlowControl.py", line 336, in
Cython.Compiler.FlowControl.NameAssignment.__deepcopy__
(/usr/src/rpmbuild/BUILD/Cython-0.23/Cython/Compiler/FlowControl.c:10989)
  File "/usr/lib64/python2.7/copy.py", line 190, in deepcopy
    y = _reconstruct(x, rv, 1, memo)
  File "/usr/lib64/python2.7/copy.py", line 328, in _reconstruct
    args = deepcopy(args, memo)
  File "/usr/lib64/python2.7/copy.py", line 163, in deepcopy
    y = copier(x, memo)
  File "/usr/lib64/python2.7/copy.py", line 237, in _deepcopy_tuple
    y.append(deepcopy(a, memo))
  File "/usr/lib64/python2.7/copy.py", line 163, in deepcopy
    y = copier(x, memo)
  File "/usr/lib64/python2.7/copy.py", line 230, in _deepcopy_list
    y.append(deepcopy(a, memo))
  File "/usr/lib64/python2.7/copy.py", line 174, in deepcopy
    y = copier(memo)
  File "Cython/Compiler/FlowControl.py", line 418, in
Cython.Compiler.FlowControl.NameReference.__deepcopy__
(/usr/src/rpmbuild/BUILD/Cython-0.23/Cython/Compiler/FlowControl.c:13685)
  File "/usr/lib64/python2.7/copy.py", line 190, in deepcopy
    y = _reconstruct(x, rv, 1, memo)
  File "/usr/lib64/python2.7/copy.py", line 334, in _reconstruct
    state = deepcopy(state, memo)
  File "/usr/lib64/python2.7/copy.py", line 163, in deepcopy
    y = copier(x, memo)
  File "/usr/lib64/python2.7/copy.py", line 257, in _deepcopy_dict
    y[deepcopy(key, memo)] = deepcopy(value, memo)
  File "/usr/lib64/python2.7/copy.py", line 190, in deepcopy
    y = _reconstruct(x, rv, 1, memo)
  File "/usr/lib64/python2.7/copy.py", line 351, in _reconstruct
    item = deepcopy(item, memo)
  File "/usr/lib64/python2.7/copy.py", line 174, in deepcopy
    y = copier(memo)
  File "Cython/Compiler/FlowControl.py", line 336, in
Cython.Compiler.FlowControl.NameAssignment.__deepcopy__
(/usr/src/rpmbuild/BUILD/Cython-0.23/Cython/Compiler/FlowControl.c:10989)
....
Sorry for not testing the 0.23 beta, which might have caught this sooner.

Cheers
Antoine


On 09/08/15 01:47, Stefan Behnel wrote:
> Hi everyone,
>
> given the positive feedback on the previous beta releases, I'm happy to
> announce the final release of Cython 0.23. There were only minor changes
> and fixes since the second beta.
>
> https://pypi.python.org/pypi/Cython/0.23
>
> This is a major feature release. Highlights include, in addition to several
> important bug fixes:
>
>   * PEP 492 (async/await) and PEP 448 (star-unpacking generalizations)
>   * inlined generator expressions
>   * support for the C++ assignment and bool() operators
>   * support for coverage analysis
>
> Complete changelog follows below. Upgrading is generally recommended.
>
>
> You can get the signed release from here:
>
> http://cython.org/
>
> http://cython.org/release/Cython-0.23.tar.gz
>
> http://cython.org/release/Cython-0.23.zip
>
>
> SHA1 sums:
> 5a49123b39d89a20fb88bdc7886210c39cdff695  Cython-0.23.tar.gz
> 9bec6c6df861be49ed608a0ab688b67bba543abe  Cython-0.23.zip
>
> Have fun,
>
> Stefan
>
>
>
> 0.23 (2015-08-08)
> =================
>
> 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.
>
> * Smart pointers were added to the provided C++ STL declarations.
>   Patch by Daniel Filonik.
>
> * ``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/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 Python dicts.
>
> * When compiling a module ``foo.pyx``, the directories in ``sys.path``
>   are no longer searched when looking for ``foo.pxd``.
>   Patch by Jeroen Demeyer.
>
> * Memory leaks in the embedding main function were fixed.
>   Original patch by Michael En?lin.
>
> * Some complex Python expressions could fail to compile inside of finally
>   clauses.
>
> * Unprefixed 'str' literals were not supported as C varargs arguments.
>
> * Fixed type errors in conversion enum types to/from Python.  Note that
>   this imposes stricter correctness requirements on enum declarations.
>
> Other changes
> -------------
>
> * Changed mangling scheme in header files generated by ``cdef api``
>   declarations.
>
> * 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.
>
> * ``jedi-typer.py`` (in ``Tools/``) was extended and renamed to
>   ``jedityper.py`` (to make it importable) and now works with and
>   requires Jedi 0.9.  Patch by Tzer-jen Wei.
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> https://mail.python.org/mailman/listinfo/cython-devel


From robertwb at gmail.com  Wed Aug 12 22:32:57 2015
From: robertwb at gmail.com (Robert Bradshaw)
Date: Wed, 12 Aug 2015 13:32:57 -0700
Subject: [Cython] [cython-users] Confusing error when trying to get
 non-existent attribute of cimported library
In-Reply-To: <CAGRr6BHicN1sCCJkaCQaHt+awBDy2YieNOcmb1QsQ9_-MRXsLg@mail.gmail.com>
References: <CAGRr6BHicN1sCCJkaCQaHt+awBDy2YieNOcmb1QsQ9_-MRXsLg@mail.gmail.com>
Message-ID: <CADiQ+QAUj72vL1wEa8qeF4RizWAr1Ni0AUrDRvaN8o+_YLV4EQ@mail.gmail.com>

On Tue, Aug 11, 2015 at 9:10 PM, Antony Lee <antony.lee at berkeley.edu> wrote:
> Compiling and running
>
> from libc cimport math
> def f():
>     print(math.abs(-1)) # oops, should be fabs
>
> results in NameError, name 'math' is not defined.  I guess that this results
> from the fact that cimported names and other names effectively live in
> different namespaces, but this is a bit confusing.

Agreed, this confusing.

We do want to support

    from libc cimport math
    import math

    math.somthing_that_only_exists_in_the_python_module()

I'm not sure we need to support

    from libc cimport math
    globals()['math'] = whatever
    math.somthing_that_only_exists_in_whatever

We've long wanted to restrict arbitrary writes to a Cython module's
global namespace... and of course such writes already aren't respected
by compile-time bindings, so is anyone opposed to making this an
error?

- Robert

From phil at riverbankcomputing.com  Wed Aug 12 19:34:21 2015
From: phil at riverbankcomputing.com (Phil Thompson)
Date: Wed, 12 Aug 2015 18:34:21 +0100
Subject: [Cython] Cython Modules as builtins
Message-ID: <F88ABF39-6F7C-47FD-A8D9-BF97DE17D432@riverbankcomputing.com>

Is there any reason why cython generated modules don?t use the fully qualified name (ie. __Pyx_MODULE_NAME) in the call to Py_InitModule4() and the PyModuleDef structure? I want to statically link a module and add it to Python?s inittab but things don?t work without a fully qualified name.

Thanks,
Phil

From jwilk at jwilk.net  Fri Aug 14 10:41:26 2015
From: jwilk at jwilk.net (Jakub Wilk)
Date: Fri, 14 Aug 2015 10:41:26 +0200
Subject: [Cython] Cython 0.23: long + int == int
Message-ID: <20150814084126.GA8121@jwilk.net>

$ cython --version
Cython version 0.23
$ python2.6 --version
Python 2.6.8
$ cat testlong.pyx
def f(x):
        return 0L + x
$ python2.6 -c 'import pyximport as p; p.install(); import testlong; print type(testlong.f(42))'
<type 'int'>

I added a long to an int, so I'd expect the result to be a long.
This works correctly in Python 2.7:

$ python2.7 -c 'import pyximport as p; p.install(); import testlong; print type(testlong.f(42))'
<type 'long'>

It also worked correctly in Cython 0.22.1 + Python 2.6.

-- 
Jakub Wilk

From antoine at nagafix.co.uk  Mon Aug 17 06:09:09 2015
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Mon, 17 Aug 2015 11:09:09 +0700
Subject: [Cython] Cython 0.23 released
In-Reply-To: <55C6F939.1040501@nagafix.co.uk>
References: <55C64ED4.7050302@behnel.de> <55C6F939.1040501@nagafix.co.uk>
Message-ID: <55D15E65.4080504@nagafix.co.uk>

On 09/08/15 13:54, Antoine Martin wrote:
> Hi,
>
> I've just hit a regression with 0.23: a recursion loop generating code
> for this particular pyx:
> http://xpra.org/trac/browser/xpra/trunk/src/xpra/codecs/nvenc4/encoder.pyx
>
> I don't think we have such loops in our setup.py data structures or in
> that pyx, but that's possible. (I will try to check later)
> The same code builds fine on all platforms with Cython 0.22.1.
I have narrowed it down to the problematic finally block via trial and
error:
http://xpra.org/trac/browser/xpra/trunk/src/xpra/codecs/nvenc4/encoder.pyx#L2024
Any of those statements, including the simple logging ones, cause
Cython's "fresh_finally_clause" code to go into an infinite loop via
deepcopy.

This "fixes" it by moving the statements out of the finally block
(obviously not a practical solution):
--- xpra/codecs/nvenc4/encoder.pyx    (revision 10311)
+++ xpra/codecs/nvenc4/encoder.pyx    (working copy)
@@ -2022,16 +2022,17 @@
             self.bytes_out += size
             data = (<char *> lockOutputBuffer.bitstreamBufferPtr)[:size]
         finally:
-            if DEBUG_API:
-                log("nvEncUnlockBitstream(%#x)", <unsigned long>
self.bitstreamBuffer)
-            with nogil:
-                r =
self.functionList.nvEncUnlockBitstream(self.context, self.bitstreamBuffer)
-            raiseNVENC(r, "unlocking output buffer")
-            if DEBUG_API:
-                log("nvEncUnmapInputResource(%#x)", <unsigned long>
self.bitstreamBuffer)
-            with nogil:
-                r =
self.functionList.nvEncUnmapInputResource(self.context,
mapInputResource.mappedResource)
-            raiseNVENC(r, "unmapping input resource")
+            pass
+        if DEBUG_API:
+            log("nvEncUnlockBitstream(%#x)", <unsigned long>
self.bitstreamBuffer)
+        with nogil:
+            r = self.functionList.nvEncUnlockBitstream(self.context,
self.bitstreamBuffer)
+        raiseNVENC(r, "unlocking output buffer")
+        if DEBUG_API:
+            log("nvEncUnmapInputResource(%#x)", <unsigned long>
self.bitstreamBuffer)
+        with nogil:
+            r = self.functionList.nvEncUnmapInputResource(self.context,
mapInputResource.mappedResource)
+        raiseNVENC(r, "unmapping input resource")
 
         download_end = time.time()
         log("compress_image(..) download took %.1f ms",
(download_end-encode_end)*1000.0)

What am I doing wrong here?
Those statements look fine and they used to compile just fine too.

Thanks
Antoine

>
> Full stack trace attached to this email. Loop excerpt:
>   File "Cython/Compiler/FlowControl.py", line 336, in
> Cython.Compiler.FlowControl.NameAssignment.__deepcopy__
> (/usr/src/rpmbuild/BUILD/Cython-0.23/Cython/Compiler/FlowControl.c:10989)
>   File "/usr/lib64/python2.7/copy.py", line 190, in deepcopy
>     y = _reconstruct(x, rv, 1, memo)
>   File "/usr/lib64/python2.7/copy.py", line 328, in _reconstruct
>     args = deepcopy(args, memo)
>   File "/usr/lib64/python2.7/copy.py", line 163, in deepcopy
>     y = copier(x, memo)
>   File "/usr/lib64/python2.7/copy.py", line 237, in _deepcopy_tuple
>     y.append(deepcopy(a, memo))
>   File "/usr/lib64/python2.7/copy.py", line 163, in deepcopy
>     y = copier(x, memo)
>   File "/usr/lib64/python2.7/copy.py", line 230, in _deepcopy_list
>     y.append(deepcopy(a, memo))
>   File "/usr/lib64/python2.7/copy.py", line 174, in deepcopy
>     y = copier(memo)
>   File "Cython/Compiler/FlowControl.py", line 418, in
> Cython.Compiler.FlowControl.NameReference.__deepcopy__
> (/usr/src/rpmbuild/BUILD/Cython-0.23/Cython/Compiler/FlowControl.c:13685)
>   File "/usr/lib64/python2.7/copy.py", line 190, in deepcopy
>     y = _reconstruct(x, rv, 1, memo)
>   File "/usr/lib64/python2.7/copy.py", line 334, in _reconstruct
>     state = deepcopy(state, memo)
>   File "/usr/lib64/python2.7/copy.py", line 163, in deepcopy
>     y = copier(x, memo)
>   File "/usr/lib64/python2.7/copy.py", line 257, in _deepcopy_dict
>     y[deepcopy(key, memo)] = deepcopy(value, memo)
>   File "/usr/lib64/python2.7/copy.py", line 190, in deepcopy
>     y = _reconstruct(x, rv, 1, memo)
>   File "/usr/lib64/python2.7/copy.py", line 351, in _reconstruct
>     item = deepcopy(item, memo)
>   File "/usr/lib64/python2.7/copy.py", line 174, in deepcopy
>     y = copier(memo)
>   File "Cython/Compiler/FlowControl.py", line 336, in
> Cython.Compiler.FlowControl.NameAssignment.__deepcopy__
> (/usr/src/rpmbuild/BUILD/Cython-0.23/Cython/Compiler/FlowControl.c:10989)
> ....
> Sorry for not testing the 0.23 beta, which might have caught this sooner.
>
> Cheers
> Antoine
>
>
> On 09/08/15 01:47, Stefan Behnel wrote:
>> Hi everyone,
>>
>> given the positive feedback on the previous beta releases, I'm happy to
>> announce the final release of Cython 0.23. There were only minor changes
>> and fixes since the second beta.
>>
>> https://pypi.python.org/pypi/Cython/0.23
>>
>> This is a major feature release. Highlights include, in addition to several
>> important bug fixes:
>>
>>   * PEP 492 (async/await) and PEP 448 (star-unpacking generalizations)
>>   * inlined generator expressions
>>   * support for the C++ assignment and bool() operators
>>   * support for coverage analysis
>>
>> Complete changelog follows below. Upgrading is generally recommended.
>>
>>
>> You can get the signed release from here:
>>
>> http://cython.org/
>>
>> http://cython.org/release/Cython-0.23.tar.gz
>>
>> http://cython.org/release/Cython-0.23.zip
>>
>>
>> SHA1 sums:
>> 5a49123b39d89a20fb88bdc7886210c39cdff695  Cython-0.23.tar.gz
>> 9bec6c6df861be49ed608a0ab688b67bba543abe  Cython-0.23.zip
>>
>> Have fun,
>>
>> Stefan
>>
>>
>>
>> 0.23 (2015-08-08)
>> =================
>>
>> 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.
>>
>> * Smart pointers were added to the provided C++ STL declarations.
>>   Patch by Daniel Filonik.
>>
>> * ``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/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 Python dicts.
>>
>> * When compiling a module ``foo.pyx``, the directories in ``sys.path``
>>   are no longer searched when looking for ``foo.pxd``.
>>   Patch by Jeroen Demeyer.
>>
>> * Memory leaks in the embedding main function were fixed.
>>   Original patch by Michael En?lin.
>>
>> * Some complex Python expressions could fail to compile inside of finally
>>   clauses.
>>
>> * Unprefixed 'str' literals were not supported as C varargs arguments.
>>
>> * Fixed type errors in conversion enum types to/from Python.  Note that
>>   this imposes stricter correctness requirements on enum declarations.
>>
>> Other changes
>> -------------
>>
>> * Changed mangling scheme in header files generated by ``cdef api``
>>   declarations.
>>
>> * 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.
>>
>> * ``jedi-typer.py`` (in ``Tools/``) was extended and renamed to
>>   ``jedityper.py`` (to make it importable) and now works with and
>>   requires Jedi 0.9.  Patch by Tzer-jen Wei.
>> _______________________________________________
>> cython-devel mailing list
>> cython-devel at python.org
>> https://mail.python.org/mailman/listinfo/cython-devel



From stefan_ml at behnel.de  Mon Aug 17 08:17:44 2015
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 17 Aug 2015 08:17:44 +0200
Subject: [Cython] Cython 0.23 released
In-Reply-To: <55D15E65.4080504@nagafix.co.uk>
References: <55C64ED4.7050302@behnel.de> <55C6F939.1040501@nagafix.co.uk>
 <55D15E65.4080504@nagafix.co.uk>
Message-ID: <55D17C88.4030506@behnel.de>

Antoine Martin schrieb am 17.08.2015 um 06:09:
> On 09/08/15 13:54, Antoine Martin wrote:
>> I've just hit a regression with 0.23: a recursion loop generating code
>> for this particular pyx:
>> http://xpra.org/trac/browser/xpra/trunk/src/xpra/codecs/nvenc4/encoder.pyx
> 
> I have narrowed it down to the problematic finally block via trial and
> error:
> http://xpra.org/trac/browser/xpra/trunk/src/xpra/codecs/nvenc4/encoder.pyx#L2024
> Any of those statements, including the simple logging ones, cause
> Cython's "fresh_finally_clause" code to go into an infinite loop via
> deepcopy.
> 
> What am I doing wrong here?
> Those statements look fine and they used to compile just fine too.

Thanks for the report. This is a bug in the latest Cython release. I'll see
if I can come up with a fix.

Stefan


From stefan_ml at behnel.de  Mon Aug 17 09:14:58 2015
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 17 Aug 2015 09:14:58 +0200
Subject: [Cython] Cython 0.23 released
In-Reply-To: <55D17C88.4030506@behnel.de>
References: <55C64ED4.7050302@behnel.de> <55C6F939.1040501@nagafix.co.uk>
 <55D15E65.4080504@nagafix.co.uk> <55D17C88.4030506@behnel.de>
Message-ID: <55D189F2.70004@behnel.de>

Stefan Behnel schrieb am 17.08.2015 um 08:17:
> Antoine Martin schrieb am 17.08.2015 um 06:09:
>> On 09/08/15 13:54, Antoine Martin wrote:
>>> I've just hit a regression with 0.23: a recursion loop generating code
>>> for this particular pyx:
>>> http://xpra.org/trac/browser/xpra/trunk/src/xpra/codecs/nvenc4/encoder.pyx
>>
>> I have narrowed it down to the problematic finally block via trial and
>> error:
>> http://xpra.org/trac/browser/xpra/trunk/src/xpra/codecs/nvenc4/encoder.pyx#L2024
>> Any of those statements, including the simple logging ones, cause
>> Cython's "fresh_finally_clause" code to go into an infinite loop via
>> deepcopy.
>>
>> What am I doing wrong here?
>> Those statements look fine and they used to compile just fine too.
> 
> Thanks for the report. This is a bug in the latest Cython release. I'll see
> if I can come up with a fix.

I couldn't reproduce it with any reasonable amount of test code yet, but
does this fix it for you?

https://github.com/cython/cython/commit/5a40d5459aad1c6f15fb8526f0144d3c0f1dfe76

Stefan


From antoine at nagafix.co.uk  Mon Aug 17 14:14:51 2015
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Mon, 17 Aug 2015 19:14:51 +0700
Subject: [Cython] Cython 0.23 released
In-Reply-To: <55D189F2.70004@behnel.de>
References: <55C64ED4.7050302@behnel.de> <55C6F939.1040501@nagafix.co.uk>
 <55D15E65.4080504@nagafix.co.uk> <55D17C88.4030506@behnel.de>
 <55D189F2.70004@behnel.de>
Message-ID: <55D1D03B.50409@nagafix.co.uk>

On 17/08/15 14:14, Stefan Behnel wrote:
> Stefan Behnel schrieb am 17.08.2015 um 08:17:
>> Antoine Martin schrieb am 17.08.2015 um 06:09:
>>> On 09/08/15 13:54, Antoine Martin wrote:
>>>> I've just hit a regression with 0.23: a recursion loop generating code
>>>> for this particular pyx:
>>>> http://xpra.org/trac/browser/xpra/trunk/src/xpra/codecs/nvenc4/encoder.pyx
>>> I have narrowed it down to the problematic finally block via trial and
>>> error:
>>> http://xpra.org/trac/browser/xpra/trunk/src/xpra/codecs/nvenc4/encoder.pyx#L2024
>>> Any of those statements, including the simple logging ones, cause
>>> Cython's "fresh_finally_clause" code to go into an infinite loop via
>>> deepcopy.
>>>
>>> What am I doing wrong here?
>>> Those statements look fine and they used to compile just fine too.
>> Thanks for the report. This is a bug in the latest Cython release. I'll see
>> if I can come up with a fix.
> I couldn't reproduce it with any reasonable amount of test code yet, but
> does this fix it for you?
>
> https://github.com/cython/cython/commit/5a40d5459aad1c6f15fb8526f0144d3c0f1dfe76
I am afraid not, I still get the same stacktrace.
Let me know if there's anything else I can try.

Cheers
Antoine

>
> Stefan
>
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> https://mail.python.org/mailman/listinfo/cython-devel


From stefan_ml at behnel.de  Mon Aug 17 20:33:09 2015
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 17 Aug 2015 20:33:09 +0200
Subject: [Cython] Cython 0.23: long + int == int
In-Reply-To: <20150814084126.GA8121@jwilk.net>
References: <20150814084126.GA8121@jwilk.net>
Message-ID: <55D228E5.60607@behnel.de>

Jakub Wilk schrieb am 14.08.2015 um 10:41:
> $ cython --version
> Cython version 0.23
> $ python2.6 --version
> Python 2.6.8
> $ cat testlong.pyx
> def f(x):
>        return 0L + x
> $ python2.6 -c 'import pyximport as p; p.install(); import testlong; print
> type(testlong.f(42))'
> <type 'int'>
> 
> I added a long to an int, so I'd expect the result to be a long.
> This works correctly in Python 2.7:
> 
> $ python2.7 -c 'import pyximport as p; p.install(); import testlong; print
> type(testlong.f(42))'
> <type 'long'>
> 
> It also worked correctly in Cython 0.22.1 + Python 2.6.

I understand that this is not entirely correct, but does it pose any
problems in practice? The "int" type has been removed in Py3, after all, so
this behaviour will go away all by itself as soon as support for Python 2.x
is removed at some point in the future.

Stefan


From thomas.holenstein at gmail.com  Mon Aug 17 11:29:02 2015
From: thomas.holenstein at gmail.com (Thomas Holenstein)
Date: Mon, 17 Aug 2015 11:29:02 +0200
Subject: [Cython] gcc error when compiling cython
Message-ID: <CAA0g94LXC9eLM_n_OOTTLnitYBa-+Zv_5SAwN=0FwNAAghq2Tw@mail.gmail.com>

Hey all,

recently, I had a gcc compile time error with cython. The work around
is obvious, as the problem happens when a cdef-ed numpy array in a
function is unused. Nevertheless, I feel it's useful to report the
problem I had.

The following is a test case
---------------------------------------- test.pyx
import numpy as np
cimport numpy as np

def f(np.ndarray[dtype=np.int_t, ndim=2] arg1):
    cdef np.ndarray[dtype=np.int_t, ndim=2] arr
    return 3
----------------------------------------- setup.py
from distutils.core import setup
from Cython.Build import cythonize

setup(
    ext_modules = cythonize("test.pyx"),
)
----------------------------------------------------------
This gives me the error

error: ?__pyx_pybuffernd_arr? undeclared

Full shell output:
 ~/tmp/ctest > python setup.py build_ext --inplace
running build_ext
building 'test' extension
x86_64-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv
-O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.7 -c test.c
-o build/temp.linux-x86_64-2.7/test.o
In file included from /usr/include/python2.7/numpy/ndarraytypes.h:1761:0,
                 from /usr/include/python2.7/numpy/ndarrayobject.h:17,
                 from /usr/include/python2.7/numpy/arrayobject.h:4,
                 from test.c:250:
/usr/include/python2.7/numpy/npy_1_7_deprecated_api.h:15:2: warning:
#warning "Using deprecated NumPy API, disable it by " "#defining
NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]
 #warning "Using deprecated NumPy API, disable it by " \
  ^
test.c: In function ?__pyx_pf_4test_f?:
test.c:1240:30: error: ?__pyx_pybuffernd_arr? undeclared (first use in
this function)
     __Pyx_SafeReleaseBuffer(&__pyx_pybuffernd_arr.rcbuffer->pybuffer);
                              ^
test.c:1240:30: note: each undeclared identifier is reported only once
for each function it appears in
In file included from /usr/include/python2.7/numpy/ndarrayobject.h:26:0,
                 from /usr/include/python2.7/numpy/arrayobject.h:4,
                 from test.c:250:
test.c: At top level:
/usr/include/python2.7/numpy/__multiarray_api.h:1629:1: warning:
?_import_array? defined but not used [-Wunused-function]
 _import_array(void)
 ^
In file included from /usr/include/python2.7/numpy/ufuncobject.h:327:0,
                 from test.c:251:
/usr/include/python2.7/numpy/__ufunc_api.h:241:1: warning:
?_import_umath? defined but not used [-Wunused-function]
 _import_umath(void)
 ^
error: command 'x86_64-linux-gnu-gcc' failed with exit status 1

From stefan_ml at behnel.de  Tue Aug 18 20:03:16 2015
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Tue, 18 Aug 2015 20:03:16 +0200
Subject: [Cython] Cython 0.23 released
In-Reply-To: <55D1D03B.50409@nagafix.co.uk>
References: <55C64ED4.7050302@behnel.de> <55C6F939.1040501@nagafix.co.uk>
 <55D15E65.4080504@nagafix.co.uk> <55D17C88.4030506@behnel.de>
 <55D189F2.70004@behnel.de> <55D1D03B.50409@nagafix.co.uk>
Message-ID: <55D37364.2000108@behnel.de>

Antoine Martin schrieb am 17.08.2015 um 14:14:
> On 17/08/15 14:14, Stefan Behnel wrote:
>> Stefan Behnel schrieb am 17.08.2015 um 08:17:
>>> Antoine Martin schrieb am 17.08.2015 um 06:09:
>>>> On 09/08/15 13:54, Antoine Martin wrote:
>>>>> I've just hit a regression with 0.23: a recursion loop generating code
>>>>> for this particular pyx:
>>>>> http://xpra.org/trac/browser/xpra/trunk/src/xpra/codecs/nvenc4/encoder.pyx
>>>> I have narrowed it down to the problematic finally block via trial and
>>>> error:
>>>> http://xpra.org/trac/browser/xpra/trunk/src/xpra/codecs/nvenc4/encoder.pyx#L2024
>>>> Any of those statements, including the simple logging ones, cause
>>>> Cython's "fresh_finally_clause" code to go into an infinite loop via
>>>> deepcopy.
>>>>
>>>> What am I doing wrong here?
>>>> Those statements look fine and they used to compile just fine too.
>>> Thanks for the report. This is a bug in the latest Cython release. I'll see
>>> if I can come up with a fix.
>> I couldn't reproduce it with any reasonable amount of test code yet, but
>> does this fix it for you?
>>
>> https://github.com/cython/cython/commit/5a40d5459aad1c6f15fb8526f0144d3c0f1dfe76
> I am afraid not, I still get the same stacktrace.
> Let me know if there's anything else I can try.

How about this?

https://github.com/cython/cython/commit/5fa766ac25a31b0c1addd08efd19d2d34661317b

Stefan


From dominic.sacre at gmx.de  Wed Aug 19 00:02:57 2015
From: dominic.sacre at gmx.de (=?UTF-8?B?RG9taW5pYyBTYWNyw6k=?=)
Date: Wed, 19 Aug 2015 00:02:57 +0200
Subject: [Cython] Cython fails to build if pgen is available
Message-ID: <55D3AB91.6090506@gmx.de>

Hi,

I'm getting the following error trying to build Cython 0.23:

Cython/Parser/Grammar: No such file or directory
Traceback (most recent call last):
  File "setup.py", line 289, in <module>
    compile_cython_modules(cython_profile, cython_compile_more,
cython_with_refnanny)
  File "setup.py", line 135, in compile_cython_modules
    os.path.join(parser_dir, 'graminit.c'),
  File
"/data/master/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/subprocess.py",
line 540, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command
'['/data/master/build/tmp/sysroots/x86_64-linux/usr/bin/python-native/pgen',
'Cython/Parser/Grammar', 'Cython/Parser/graminit.h',
'Cython/Parser/graminit.c']' returned non-zero exit status 1

The toolchain is based on OpenEmbedded, and unlike most distribution
packages, its Python installation actually contains pgen.

Where would that Cython/Parser/Grammar file come from?
Alternatively, is there a clean way (without patching setup.py) to skip
compiling the grammar?


Cheers,

Dominic

From robertwb at gmail.com  Wed Aug 19 00:52:59 2015
From: robertwb at gmail.com (Robert Bradshaw)
Date: Tue, 18 Aug 2015 15:52:59 -0700
Subject: [Cython] Cython fails to build if pgen is available
In-Reply-To: <55D3AB91.6090506@gmx.de>
References: <55D3AB91.6090506@gmx.de>
Message-ID: <CADiQ+QC5dOGZRnaf3BWy0P1AOoDx2p21zyWhTqw+QnP4sfrxVA@mail.gmail.com>

On Tue, Aug 18, 2015 at 3:02 PM, Dominic Sacr? <dominic.sacre at gmx.de> wrote:
> Hi,
>
> I'm getting the following error trying to build Cython 0.23:
>
> Cython/Parser/Grammar: No such file or directory
> Traceback (most recent call last):
>   File "setup.py", line 289, in <module>
>     compile_cython_modules(cython_profile, cython_compile_more,
> cython_with_refnanny)
>   File "setup.py", line 135, in compile_cython_modules
>     os.path.join(parser_dir, 'graminit.c'),
>   File
> "/data/master/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/subprocess.py",
> line 540, in check_call
>     raise CalledProcessError(retcode, cmd)
> subprocess.CalledProcessError: Command
> '['/data/master/build/tmp/sysroots/x86_64-linux/usr/bin/python-native/pgen',
> 'Cython/Parser/Grammar', 'Cython/Parser/graminit.h',
> 'Cython/Parser/graminit.c']' returned non-zero exit status 1
>
> The toolchain is based on OpenEmbedded, and unlike most distribution
> packages, its Python installation actually contains pgen.
>
> Where would that Cython/Parser/Grammar file come from?
> Alternatively, is there a clean way (without patching setup.py) to skip
> compiling the grammar?

The grammar is here: https://github.com/cython/cython/tree/master/Cython/Parser

Looks like eveyone who tried to use this did so from a git clone, not
the sdist. Omission fixed:
https://github.com/cython/cython/commit/969de4eab048896c6f29b9251dc4324309a1abb4
Either patch this in/distribute these files or patch setup.py.

From antoine at nagafix.co.uk  Wed Aug 19 04:28:08 2015
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Wed, 19 Aug 2015 09:28:08 +0700
Subject: [Cython] Cython 0.23 released
In-Reply-To: <55D37364.2000108@behnel.de>
References: <55C64ED4.7050302@behnel.de> <55C6F939.1040501@nagafix.co.uk>
 <55D15E65.4080504@nagafix.co.uk> <55D17C88.4030506@behnel.de>
 <55D189F2.70004@behnel.de> <55D1D03B.50409@nagafix.co.uk>
 <55D37364.2000108@behnel.de>
Message-ID: <55D3E9B8.30001@nagafix.co.uk>

On 19/08/15 01:03, Stefan Behnel wrote:
> Antoine Martin schrieb am 17.08.2015 um 14:14:
>> On 17/08/15 14:14, Stefan Behnel wrote:
>>> Stefan Behnel schrieb am 17.08.2015 um 08:17:
>>>> Antoine Martin schrieb am 17.08.2015 um 06:09:
>>>>> On 09/08/15 13:54, Antoine Martin wrote:
>>>>>> I've just hit a regression with 0.23: a recursion loop generating code
>>>>>> for this particular pyx:
>>>>>> http://xpra.org/trac/browser/xpra/trunk/src/xpra/codecs/nvenc4/encoder.pyx
>>>>> I have narrowed it down to the problematic finally block via trial and
>>>>> error:
>>>>> http://xpra.org/trac/browser/xpra/trunk/src/xpra/codecs/nvenc4/encoder.pyx#L2024
>>>>> Any of those statements, including the simple logging ones, cause
>>>>> Cython's "fresh_finally_clause" code to go into an infinite loop via
>>>>> deepcopy.
>>>>>
>>>>> What am I doing wrong here?
>>>>> Those statements look fine and they used to compile just fine too.
>>>> Thanks for the report. This is a bug in the latest Cython release. I'll see
>>>> if I can come up with a fix.
>>> I couldn't reproduce it with any reasonable amount of test code yet, but
>>> does this fix it for you?
>>>
>>> https://github.com/cython/cython/commit/5a40d5459aad1c6f15fb8526f0144d3c0f1dfe76
>> I am afraid not, I still get the same stacktrace.
>> Let me know if there's anything else I can try.
> How about this?
>
> https://github.com/cython/cython/commit/5fa766ac25a31b0c1addd08efd19d2d34661317b
That fixes it!

Thank you very much.

Antoine


>
> Stefan
>
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> https://mail.python.org/mailman/listinfo/cython-devel


From jwilk at jwilk.net  Thu Aug 20 11:52:10 2015
From: jwilk at jwilk.net (Jakub Wilk)
Date: Thu, 20 Aug 2015 11:52:10 +0200
Subject: [Cython] Cython 0.23: long + int == int
In-Reply-To: <55D228E5.60607@behnel.de>
References: <20150814084126.GA8121@jwilk.net>
 <55D228E5.60607@behnel.de>
Message-ID: <20150820095210.GA6969@jwilk.net>

* Stefan Behnel <stefan_ml at behnel.de>, 2015-08-17, 20:33:
>>$ cat testlong.pyx
>>def f(x):
>>       return 0L + x
>>$ python2.6 -c 'import pyximport as p; p.install(); import testlong; print
>>type(testlong.f(42))'
>><type 'int'>
>>
>>I added a long to an int, so I'd expect the result to be a long.
[...]
>I understand that this is not entirely correct, but does it pose any 
>problems in practice?

It broke my test suite, which is how I noticed; but yeah, I don't think 
it's a big deal.

-- 
Jakub Wilk

From stefan_ml at behnel.de  Sat Aug 22 08:29:49 2015
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sat, 22 Aug 2015 08:29:49 +0200
Subject: [Cython] gcc error when compiling cython
In-Reply-To: <CAA0g94LXC9eLM_n_OOTTLnitYBa-+Zv_5SAwN=0FwNAAghq2Tw@mail.gmail.com>
References: <CAA0g94LXC9eLM_n_OOTTLnitYBa-+Zv_5SAwN=0FwNAAghq2Tw@mail.gmail.com>
Message-ID: <55D816DD.50802@behnel.de>

Thomas Holenstein schrieb am 17.08.2015 um 11:29:
> recently, I had a gcc compile time error with cython. The work around
> is obvious, as the problem happens when a cdef-ed numpy array in a
> function is unused. Nevertheless, I feel it's useful to report the
> problem I had.
> 
> The following is a test case
> ---------------------------------------- test.pyx
> import numpy as np
> cimport numpy as np
> 
> def f(np.ndarray[dtype=np.int_t, ndim=2] arg1):
>     cdef np.ndarray[dtype=np.int_t, ndim=2] arr
>     return 3
> ----------------------------------------- setup.py
> from distutils.core import setup
> from Cython.Build import cythonize
> 
> setup(
>     ext_modules = cythonize("test.pyx"),
> )
> ----------------------------------------------------------
> This gives me the error
> 
> error: ?__pyx_pybuffernd_arr? undeclared
> 
> Full shell output:
>  ~/tmp/ctest > python setup.py build_ext --inplace
> running build_ext
> building 'test' extension
> x86_64-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv
> -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.7 -c test.c
> -o build/temp.linux-x86_64-2.7/test.o
> test.c: In function ?__pyx_pf_4test_f?:
> test.c:1240:30: error: ?__pyx_pybuffernd_arr? undeclared (first use in
> this function)
>      __Pyx_SafeReleaseBuffer(&__pyx_pybuffernd_arr.rcbuffer->pybuffer);

Looks like this long-standing ticket:

http://trac.cython.org/ticket/154

Here's a fix:

https://github.com/cython/cython/commit/d2c1b7770571061492996e90b45a633f2f83a66a

Stefan


From stefan_ml at behnel.de  Sat Aug 22 17:55:28 2015
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sat, 22 Aug 2015 17:55:28 +0200
Subject: [Cython] Cython 0.23.1 released
Message-ID: <55D89B70.20206@behnel.de>

Hi everyone,

based on the feedback for the recent 0.23 release, here is a bug-fix-only
release that repairs several problems and regressions.

https://pypi.python.org/pypi/Cython/0.23.1

Complete changelog follows below. Upgrading is generally recommended.


You can get the signed release from here:

http://cython.org/

http://cython.org/release/Cython-0.23.1.tar.gz

http://cython.org/release/Cython-0.23.1.zip


SHA1 sums:
2ff0f863d3b996d2265d0bf06e567e5dd23d004d  Cython-0.23.1.tar.gz
42943dd9b1355015ec5d630419f93a91f4f118cb  Cython-0.23.1.zip

Have fun,

Stefan


0.23.1 (2015-08-22)
===================

Bugs fixed
----------

* Invalid C code for generators.  This fixes ticket 858.

* Invalid C code for some builtin methods.  This fixes ticket 856.

* Invalid C code for unused local buffer variables.
  This fixes ticket 154.

* Test failures on 32bit systems.  This fixes ticket 857.

* Code that uses "from xyz import *" and global C struct/union/array
  variables could fail to compile due to missing helper functions.
  This fixes ticket 851.

* Misnamed PEP 492 coroutine property ``cr_yieldfrom`` renamed to
  ``cr_await`` to match CPython.

* Missing deallocation code for C++ object attributes in certain
  extension class hierarchies.

* Crash when async coroutine was not awaited.

* Compiler crash on ``yield`` in signature annotations and default
  argument values.  Both are forbidden now.

* Compiler crash on certain constructs in ``finally`` clauses.

* Cython failed to build when CPython's pgen is installed.

From fperez.net at gmail.com  Wed Aug 26 07:24:21 2015
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 25 Aug 2015 22:24:21 -0700
Subject: [Cython] Python extensions for Python 3.5 - useful info...
Message-ID: <CAHAreOrBN7svj14gfb69+fU=aYQLi2LKNv_gVQkm+HEUX7PGPw@mail.gmail.com>

Just an FYI for the upcoming Python release, a very detailed post from
Steve Dower, the Microsoft developer who is now in charge of the Windows
releases for Python, on how the build process will change in 3.5 regarding
extensions:

http://stevedower.id.au/blog/building-for-python-3-5/

Cheers,

f
-- 
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20150825/1304be9b/attachment.html>

From jwilk at jwilk.net  Sun Aug 30 21:29:47 2015
From: jwilk at jwilk.net (Jakub Wilk)
Date: Sun, 30 Aug 2015 21:29:47 +0200
Subject: [Cython] Compiler crash in MarkOverflowingArithmetic
Message-ID: <20150830192947.GA6187@jwilk.net>

Tested with Cython 0.23.1 on i386. You will probably need a bigger 
number to trigger it on a 64-bit machine.

$ cython test.pyx

Error compiling Cython file:
------------------------------------------------------------
...
DEF X = 0x811C9DC5
cdef void f():
    cdef unsigned int x = X
        ^
------------------------------------------------------------

test.pyx:3:9: Compiler crash in MarkOverflowingArithmetic

ModuleNode.body = StatListNode(test.pyx:2:5)
StatListNode.stats[0] = CFuncDefNode(test.pyx:2:5,
    args = [...]/0,
    modifiers = [...]/0,
    visibility = 'private')
CFuncDefNode.body = StatListNode(test.pyx:3:9)
StatListNode.stats[0] = SingleAssignmentNode(test.pyx:3:9,
    first = True)

Compiler crash traceback from this point on:
  File "/usr/local/lib/python2.7/dist-packages/Cython/Compiler/Visitor.py", line 183, in _visit
    return handler_method(obj)
  File "/usr/local/lib/python2.7/dist-packages/Cython/Compiler/TypeInference.py", line 327, in visit_SingleAssignmentNode
    self.visit_assignment(node.lhs, node.rhs)
  File "/usr/local/lib/python2.7/dist-packages/Cython/Compiler/TypeInference.py", line 321, in visit_assignment
    and Utils.long_literal(rhs.value)):
  File "/usr/local/lib/python2.7/dist-packages/Cython/Utils.py", line 318, in long_literal
    value = str_to_number(value)
  File "/usr/local/lib/python2.7/dist-packages/Cython/Utils.py", line 312, in str_to_number
    value = int(value, 0)
ValueError: invalid literal for int() with base 0: '2166136261L'

-- 
Jakub Wilk
-------------- next part --------------
DEF X = 0x811C9DC5
cdef void f():
    cdef unsigned int x = X

From jwilk at jwilk.net  Sun Aug 30 19:44:00 2015
From: jwilk at jwilk.net (Jakub Wilk)
Date: Sun, 30 Aug 2015 19:44:00 +0200
Subject: [Cython] DEF converts byte strings to unicode
Message-ID: <20150830174400.GA8322@jwilk.net>

DEF silently converts byte strings to Unicode strings:

$ cat testcase.pyx
DEF ABYTE = b'a'
print type(ABYTE)

$ python --version
Python 2.7.10

$ python -c 'import pyximport as p; p.install(); import testcase'
<type 'unicode'>


Tested with Cython 0.23.1.

-- 
Jakub Wilk