Mailman 3 September 2015 - cython-devel

Cython 0.23.2 released
by Stefan Behnel Sept. 11, 2015

Sept. 11, 2015

Hi everyone, here is a second bug-fix release for the 0.23 release series that repairs several problems and regressions. https://pypi.python.org/pypi/Cython/0.23.2 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.2.tar.gz http://cython.org/release/Cython-0.23.2.zip SHA1 sums: 196bcc55bc82da7e096b28f4eeb848d46a516b21 Cython-0.23.2.tar.gz 7e6aeb8ea81780c65178fa43c9e2b217b2561f8f Cython-0.23.2.zip Have fun, Stefan 0.23.2 (2015-09-11) =================== Bugs fixed ---------- * Compiler crash when analysing some optimised expressions. * Coverage plugin was adapted to coverage.py 4.0 beta 2. * C++ destructor calls could fail when '&' operator is overwritten. * Incorrect C literal generation for large integers in compile-time evaluated DEF expressions and constant folded expressions. * Byte string constants could end up as Unicode strings when originating from compile-time evaluated DEF expressions. * Invalid C code when caching known builtin methods. This fixes ticket 860. * ``ino_t`` in ``posix.types`` was not declared as ``unsigned``. * Declarations in ``libcpp/memory.pxd`` were missing ``operator!()``. Patch by Leo Razoumov. * Static cdef methods can now be declared in .pxd files.

1 0

Re: [Cython] [cython-users] call for contribution: PEP 498 - Literal String Interpolation
by Jelle Zijlstra Sept. 9, 2015

Sept. 9, 2015

I would be interested in doing this, although I haven't previously worked on Cython itself. I'll start looking into it over the weekend. 2015-09-09 7:35 GMT-07:00 Jelle Zijlstra <jelle.zijlstra(a)gmail.com>: > I would be interested in doing this, although I haven't previously worked > on Cython itself. I'll start looking into it over the weekend. > > 2015-09-05 11:32 GMT-07:00 Stefan Behnel <stefan_ml(a)behnel.de>: > >> Hi! >> >> It looks like PEP 498 (f-strings) is going to be accepted soon. Anyone >> interested in implementing it for Cython? >> >> https://www.python.org/dev/peps/pep-0498/ >> >> It's certainly a bit of work, but it's also very much Python-level >> functionality and most of it can be handled in the parser, so I would >> count >> it as an entry-level project for working on Cython. There is already an >> initial implementation for CPython (in C) which should provide an answer >> to >> the tricky details of the functionality itself, as well as tests for it >> (eventually). >> >> https://bugs.python.org/issue24965 >> >> So, if this feature, and if extending the Cython language and working on a >> real compiler sounds tempting to you, please speak up on the cython-devel >> mailing list. >> >> Stefan >> >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "cython-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to cython-users+unsubscribe(a)googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > >

1 0

Re: [Cython] call for contribution: PEP 498 - Literal String Interpolation
by Fabrizio Messina Sept. 8, 2015

Sept. 8, 2015

Hello, I would like to give a look on that on my spare time. On 5 Sep 2015 20:32, "Stefan Behnel" <stefan_ml(a)behnel.de> wrote: Hi! It looks like PEP 498 (f-strings) is going to be accepted soon. Anyone interested in implementing it for Cython? https://www.python.org/dev/peps/pep-0498/ It's certainly a bit of work, but it's also very much Python-level functionality and most of it can be handled in the parser, so I would count it as an entry-level project for working on Cython. There is already an initial implementation for CPython (in C) which should provide an answer to the tricky details of the functionality itself, as well as tests for it (eventually). https://bugs.python.org/issue24965 So, if this feature, and if extending the Cython language and working on a real compiler sounds tempting to you, please speak up on the cython-devel mailing list. Stefan _______________________________________________ cython-devel mailing list cython-devel(a)python.org https://mail.python.org/mailman/listinfo/cython-devel

2 2

Re: [Cython] [cython-users] Integer division
by Robert Bradshaw Sept. 8, 2015

Sept. 8, 2015

On Mon, Sep 7, 2015 at 5:42 PM, Antony Lee <antony.lee(a)berkeley.edu> wrote: > My 2c (not cc'ed to cython-devel, as I am not registered): > > - language_level=3 implies __future__ division. > - if __future__ division is set: int / int => float (whether variables are > untyped (= typed at runtime by python) or typed (including by the > inferencer)) > - if __future__ division is not set: int / int => int, with > opposite-sign-case and zero-divisor-case handled depending on cdivision > - in both cases, int // int => int, with opposite-sign-case and > zero-divisor-case handled depending on cdivision (also for % and divmod). That's what I'm leaning towards as well, but it is backwards incompatible. Anyone else have any opinions? > 2015-09-07 17:15 GMT-07:00 Robert Bradshaw <robertwb(a)gmail.com>: >> >> Or perhaps we should respect float division even with cdivision... >> Thoughts? >> >> On Mon, Sep 7, 2015 at 5:13 PM, Robert Bradshaw <robertwb(a)gmail.com> >> wrote: >> > Oh, that's another issue. I'll clarify this in the documentation. >> > >> > On Mon, Sep 7, 2015 at 3:59 PM, Antony Lee <antony.lee(a)berkeley.edu> >> > wrote: >> >> Actually I realized that it's another problem; setting cdivision to >> >> True (as >> >> I did in the directive of the example I gave, because I basically >> >> always set >> >> this to True) overrides __future__ division and restores the C division >> >> semantic that int / int = int. The documentation actually says that >> >> the >> >> cdivision directive should only affect the case of operands with >> >> different >> >> signs and of division by zero, not whether int / int = int. >> >> Antony >> >> >> >> 2015-09-07 15:50 GMT-07:00 Robert Bradshaw <robertwb(a)gmail.com>: >> >>> >> >>> On Mon, Sep 7, 2015 at 3:46 PM, Robert Bradshaw <robertwb(a)gmail.com> >> >>> wrote: >> >>> > On Mon, Sep 7, 2015 at 3:29 PM, Antony Lee <antony.lee(a)berkeley.edu> >> >>> > wrote: >> >>> >> Sorry, I intended the entire discussion to apply to the case of >> >>> >> Python3 >> >>> >> semantics. Indeed, even with language_level=3 and from __future__ >> >>> >> import >> >>> >> division, foo.decl(3, 3) prints "1, 2, 0, 1" whereas foo.nodecl(3, >> >>> >> 3) >> >>> >> prints >> >>> >> "1.0, 0.5, 2.0, 1.0". >> >>> > >> >>> > from __future__ import division behaves as expected; I just added >> >>> > some >> >>> > even more explicit tests: >> >>> > >> >>> > >> >>> > https://github.com/cython/cython/commit/e61da2eb8a292bc34285c895aade523b6d3… >> >>> > >> >>> > I'm surprised language_level=3 doesn't automatically set this >> >>> > directive. >> >>> >> >>> Are you sure you're setting it correctly? >> >>> https://github.com/cython/cython/blob/master/tests/run/cython3.pyx#L30 >> >>> >> >>> >> 2015-09-07 15:07 GMT-07:00 Robert Bradshaw <robertwb(a)gmail.com>: >> >>> >>> >> >>> >>> On Mon, Sep 7, 2015 at 11:59 AM, Antony Lee >> >>> >>> <antony.lee(a)berkeley.edu> >> >>> >>> wrote: >> >>> >>> > I would like to suggest that division of integers with "/" >> >>> >>> > prints a >> >>> >>> > warning >> >>> >>> > at compile time. In my opinion, "/" should be restricted to >> >>> >>> > float >> >>> >>> > division, >> >>> >>> > and "//" should be used when rounding semantics are required. >> >>> >>> > >> >>> >>> > Otherwise, we get weird edge cases such as: >> >>> >>> > >> >>> >>> > #cython: cdivision=True, infer_types=True >> >>> >>> > def decl(int m, int n): >> >>> >>> > for i in range(1, m): >> >>> >>> > for j in range(1, n): >> >>> >>> > print(i / j) # integer division >> >>> >>> > >> >>> >>> > def nodecl(m, n): >> >>> >>> > for i in range(1, m): >> >>> >>> > for j in range(1, n): >> >>> >>> > print(i / j) # float division >> >>> >>> >> >>> >>> Slight correction: int or float division depending on whether >> >>> >>> you're >> >>> >>> using Python 2 or Python 3. The runtime type of i/j isn't >> >>> >>> something we >> >>> >>> can delegate to the C compiler. >> >>> >>> >> >>> >>> > (whose behavior may even change if type inference rules >> >>> >>> > changes). >> >>> >>> > >> >>> >>> > A more extreme choice would be to have "/" always behave like >> >>> >>> > float >> >>> >>> > (double) >> >>> >>> > division even with integer arguments. >> >>> >>> >> >>> >>> You mean like putting from __future__ import division at the top >> >>> >>> of >> >>> >>> your file? Or compiling with -3 (for Python 3 language semantics)? >> >>> >>> >> >>> >>> -- >> >>> >>> >> >>> >>> --- >> >>> >>> You received this message because you are subscribed to the Google >> >>> >>> Groups >> >>> >>> "cython-users" group. >> >>> >>> To unsubscribe from this group and stop receiving emails from it, >> >>> >>> send >> >>> >>> an >> >>> >>> email to cython-users+unsubscribe(a)googlegroups.com. >> >>> >>> For more options, visit https://groups.google.com/d/optout. >> >>> >> >> >>> >> >> >>> >> -- >> >>> >> >> >>> >> --- >> >>> >> You received this message because you are subscribed to the Google >> >>> >> Groups >> >>> >> "cython-users" group. >> >>> >> To unsubscribe from this group and stop receiving emails from it, >> >>> >> send >> >>> >> an >> >>> >> email to cython-users+unsubscribe(a)googlegroups.com. >> >>> >> For more options, visit https://groups.google.com/d/optout. >> >>> >> >>> -- >> >>> >> >>> --- >> >>> You received this message because you are subscribed to the Google >> >>> Groups >> >>> "cython-users" group. >> >>> To unsubscribe from this group and stop receiving emails from it, send >> >>> an >> >>> email to cython-users+unsubscribe(a)googlegroups.com. >> >>> For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> >> -- >> >> >> >> --- >> >> You received this message because you are subscribed to the Google >> >> Groups >> >> "cython-users" group. >> >> To unsubscribe from this group and stop receiving emails from it, send >> >> an >> >> email to cython-users+unsubscribe(a)googlegroups.com. >> >> For more options, visit https://groups.google.com/d/optout. >> >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "cython-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to cython-users+unsubscribe(a)googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > > -- > > --- > You received this message because you are subscribed to the Google Groups > "cython-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to cython-users+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/d/optout.

2 1

Re: [Cython] [cython-users] Integer division
by Robert Bradshaw Sept. 7, 2015

Sept. 7, 2015

Or perhaps we should respect float division even with cdivision... Thoughts? On Mon, Sep 7, 2015 at 5:13 PM, Robert Bradshaw <robertwb(a)gmail.com> wrote: > Oh, that's another issue. I'll clarify this in the documentation. > > On Mon, Sep 7, 2015 at 3:59 PM, Antony Lee <antony.lee(a)berkeley.edu> wrote: >> Actually I realized that it's another problem; setting cdivision to True (as >> I did in the directive of the example I gave, because I basically always set >> this to True) overrides __future__ division and restores the C division >> semantic that int / int = int. The documentation actually says that the >> cdivision directive should only affect the case of operands with different >> signs and of division by zero, not whether int / int = int. >> Antony >> >> 2015-09-07 15:50 GMT-07:00 Robert Bradshaw <robertwb(a)gmail.com>: >>> >>> On Mon, Sep 7, 2015 at 3:46 PM, Robert Bradshaw <robertwb(a)gmail.com> >>> wrote: >>> > On Mon, Sep 7, 2015 at 3:29 PM, Antony Lee <antony.lee(a)berkeley.edu> >>> > wrote: >>> >> Sorry, I intended the entire discussion to apply to the case of Python3 >>> >> semantics. Indeed, even with language_level=3 and from __future__ >>> >> import >>> >> division, foo.decl(3, 3) prints "1, 2, 0, 1" whereas foo.nodecl(3, 3) >>> >> prints >>> >> "1.0, 0.5, 2.0, 1.0". >>> > >>> > from __future__ import division behaves as expected; I just added some >>> > even more explicit tests: >>> > >>> > https://github.com/cython/cython/commit/e61da2eb8a292bc34285c895aade523b6d3… >>> > >>> > I'm surprised language_level=3 doesn't automatically set this directive. >>> >>> Are you sure you're setting it correctly? >>> https://github.com/cython/cython/blob/master/tests/run/cython3.pyx#L30 >>> >>> >> 2015-09-07 15:07 GMT-07:00 Robert Bradshaw <robertwb(a)gmail.com>: >>> >>> >>> >>> On Mon, Sep 7, 2015 at 11:59 AM, Antony Lee <antony.lee(a)berkeley.edu> >>> >>> wrote: >>> >>> > I would like to suggest that division of integers with "/" prints a >>> >>> > warning >>> >>> > at compile time. In my opinion, "/" should be restricted to float >>> >>> > division, >>> >>> > and "//" should be used when rounding semantics are required. >>> >>> > >>> >>> > Otherwise, we get weird edge cases such as: >>> >>> > >>> >>> > #cython: cdivision=True, infer_types=True >>> >>> > def decl(int m, int n): >>> >>> > for i in range(1, m): >>> >>> > for j in range(1, n): >>> >>> > print(i / j) # integer division >>> >>> > >>> >>> > def nodecl(m, n): >>> >>> > for i in range(1, m): >>> >>> > for j in range(1, n): >>> >>> > print(i / j) # float division >>> >>> >>> >>> Slight correction: int or float division depending on whether you're >>> >>> using Python 2 or Python 3. The runtime type of i/j isn't something we >>> >>> can delegate to the C compiler. >>> >>> >>> >>> > (whose behavior may even change if type inference rules changes). >>> >>> > >>> >>> > A more extreme choice would be to have "/" always behave like float >>> >>> > (double) >>> >>> > division even with integer arguments. >>> >>> >>> >>> You mean like putting from __future__ import division at the top of >>> >>> your file? Or compiling with -3 (for Python 3 language semantics)? >>> >>> >>> >>> -- >>> >>> >>> >>> --- >>> >>> You received this message because you are subscribed to the Google >>> >>> Groups >>> >>> "cython-users" group. >>> >>> To unsubscribe from this group and stop receiving emails from it, send >>> >>> an >>> >>> email to cython-users+unsubscribe(a)googlegroups.com. >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >>> >> >>> >> -- >>> >> >>> >> --- >>> >> You received this message because you are subscribed to the Google >>> >> Groups >>> >> "cython-users" group. >>> >> To unsubscribe from this group and stop receiving emails from it, send >>> >> an >>> >> email to cython-users+unsubscribe(a)googlegroups.com. >>> >> For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> >>> --- >>> You received this message because you are subscribed to the Google Groups >>> "cython-users" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to cython-users+unsubscribe(a)googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "cython-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to cython-users+unsubscribe(a)googlegroups.com. >> For more options, visit https://groups.google.com/d/optout.

1 0

All DEF constants are now unsigned?
by Jeroen Demeyer Sept. 7, 2015

Sept. 7, 2015

Hello Cython-devel, I noticed that now unsigned constants like DEF foo = 1 become 1U in the C source code. This change (i.e. commit ea6414cd293ba2134c3df5b37b158d8e3db79083) broke Sage. I haven't managed yet to actually isolate why this change broke something. Was this change of 1 to 1U intentional? Why was it done? Jeroen.

3 8

call for contribution: PEP 498 - Literal String Interpolation
by Stefan Behnel Sept. 5, 2015

Sept. 5, 2015

Hi! It looks like PEP 498 (f-strings) is going to be accepted soon. Anyone interested in implementing it for Cython? https://www.python.org/dev/peps/pep-0498/ It's certainly a bit of work, but it's also very much Python-level functionality and most of it can be handled in the parser, so I would count it as an entry-level project for working on Cython. There is already an initial implementation for CPython (in C) which should provide an answer to the tricky details of the functionality itself, as well as tests for it (eventually). https://bugs.python.org/issue24965 So, if this feature, and if extending the Cython language and working on a real compiler sounds tempting to you, please speak up on the cython-devel mailing list. Stefan

1 0

overflow bug?
by Mark Florisson Sept. 5, 2015

Sept. 5, 2015

Hi, I think this might be a bug (python 3.3 + cython 0.22.1): def f(term=b"12345"): val = int('987278186585') # The below line does not work, because it treats 1 as a constant integer # in the C code (32 bit on my machine). Using 1L does work however. val -= 1 << (len(term) * 8) return val print(f()) This works in pure-python, but Cython generates '1 << __pyx_t_somevar', which I think treats the '1' as an integer (causing it to overflow). Using '1L' works in the Cython code however (but that may be just my platform). Cheers, Mark

3 2

Bootstrapping broken in master
by Jeroen Demeyer Sept. 5, 2015

Sept. 5, 2015

Checking out Cython from master (the 0.23.x branch works fine) and running "python setup.py install" gives me Unable to find pgen, not compiling formal grammar. Compiling module Cython.Compiler.Scanning ... ERROR: 'module' object has no attribute 'CCodeConfig' Extension module compilation failed, looks like Cython cannot run properly on this system. To work around this, pass the option "--no-cython-compile". This will install a pure Python version of Cython without compiling its own sources. 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 233, in compile_cython_modules result = compile(pyx_source_file) File "/usr/local/src/sage-git/local/src/cython/Cython/Compiler/Main.py", line 677, in compile return compile_single(source, options, full_module_name) File "/usr/local/src/sage-git/local/src/cython/Cython/Compiler/Main.py", line 630, in compile_single return run_pipeline(source, options, full_module_name) File "/usr/local/src/sage-git/local/src/cython/Cython/Compiler/Main.py", line 487, in run_pipeline err, enddata = Pipeline.run_pipeline(pipeline, source) File "/usr/local/src/sage-git/local/src/cython/Cython/Compiler/Pipeline.py", line 334, in run_pipeline data = phase(data) File "/usr/local/src/sage-git/local/src/cython/Cython/Compiler/Pipeline.py", line 53, in generate_pyx_code_stage module_node.process_implementation(options, result) File "/usr/local/src/sage-git/local/src/cython/Cython/Compiler/ModuleNode.py", line 118, in process_implementation self.generate_c_code(env, options, result) File "/usr/local/src/sage-git/local/src/cython/Cython/Compiler/ModuleNode.py", line 317, in generate_c_code c_code_config = Code.CCodeConfig( AttributeError: 'module' object has no attribute 'CCodeConfig'

2 1

array->memoryview typecast causes compiler crash in AnalyseExpressionsTransform
by Jakub Wilk Sept. 2, 2015

Sept. 2, 2015

In https://bugs.debian.org/793129 Dan Greene reported that trying to cast a pointer to a memoryview object causes a compiler crash: $ python -c 'import cython; cython.inline("<int[:12]>NULL")' Compiling /home/jwilk/.cython/inline/_cython_inline_ad8e8c5018441f8a5417cab08ec65d13.pyx because it changed. [1/1] Cythonizing /home/jwilk/.cython/inline/_cython_inline_ad8e8c5018441f8a5417cab08ec65d13.pyx Error compiling Cython file: ------------------------------------------------------------ ... def __invoke(): <int[:12]>NULL ^ ------------------------------------------------------------ .cython/inline/_cython_inline_ad8e8c5018441f8a5417cab08ec65d13.pyx:5:4: Compiler crash in AnalyseExpressionsTransform ModuleNode.body = StatListNode(_cython_inline_ad8e8c5018441f8a5417cab08ec65d13.pyx:4:0) StatListNode.stats[0] = DefNode(_cython_inline_ad8e8c5018441f8a5417cab08ec65d13.pyx:4:0, modifiers = [...]/0, name = u'__invoke', py_wrapper_required = True, reqd_kw_flags_cname = '0', used = True) File 'Nodes.py', line 430, in analyse_expressions: StatListNode(_cython_inline_ad8e8c5018441f8a5417cab08ec65d13.pyx:5:4, is_terminator = True) File 'Nodes.py', line 4741, in analyse_expressions: ExprStatNode(_cython_inline_ad8e8c5018441f8a5417cab08ec65d13.pyx:5:4) File 'ExprNodes.py', line 460, in analyse_expressions: CythonArrayNode(_cython_inline_ad8e8c5018441f8a5417cab08ec65d13.pyx:5:4, is_temp = True, mode = 'c', use_managed_ref = True) File 'ExprNodes.py', line 9567, in analyse_types: CythonArrayNode(_cython_inline_ad8e8c5018441f8a5417cab08ec65d13.pyx:5:4, is_temp = True, mode = 'c', use_managed_ref = True) File 'ExprNodes.py', line 9582, in get_cython_array_type: CythonArrayNode(_cython_inline_ad8e8c5018441f8a5417cab08ec65d13.pyx:5:4, is_temp = True, mode = 'c', use_managed_ref = True) Compiler crash traceback from this point on: File "/home/jwilk/.local/lib/python2.7/site-packages/Cython/Compiler/ExprNodes.py", line 9582, in get_cython_array_type return env.global_scope().context.cython_scope.viewscope.lookup("array").type AttributeError: 'CythonScope' object has no attribute 'viewscope' Traceback (most recent call last): File "<string>", line 1, in <module> File "/home/jwilk/.local/lib/python2.7/site-packages/Cython/Shadow.py", line 114, in inline return cython_inline(f, *args, **kwds) File "/home/jwilk/.local/lib/python2.7/site-packages/Cython/Build/Inline.py", line 212, in cython_inline build_extension.extensions = cythonize([extension], include_path=cython_include_dirs, quiet=quiet) File "/home/jwilk/.local/lib/python2.7/site-packages/Cython/Build/Dependencies.py", line 877, in cythonize cythonize_one(*args) File "/home/jwilk/.local/lib/python2.7/site-packages/Cython/Build/Dependencies.py", line 997, in cythonize_one raise CompileError(None, pyx_file) Cython.Compiler.Errors.CompileError: /home/jwilk/.cython/inline/_cython_inline_ad8e8c5018441f8a5417cab08ec65d13.pyx -- Jakub Wilk

1 0