[Cython] Cython-0.17 builtin type import bug
If a builtin type that differs between Python 2 and 3 (e.g., unicode)
is imported, then malformed C code is emitted by Cython-0.17: there is
an extraneous, unbalanced #if.
Here's a small reproducer:
shell$ cat foo.pyx
cdef extern from "Python.h":
ctypedef class __builtin__.unicode [object PyUnicodeObject]:
pass
shell$ cython foo.pyx
warning: foo.pyx:2:4: unicode already a builtin Cython type
shell$ gcc -c -fPIC -I/usr/include/python2.6 foo.c
foo.c:5:1: error: unterminated #else
foo.c: In function 'initfoo':
foo.c:574: error: expected declaration or statement at end of input
foo.c:535: error: label '__pyx_L1_error' used but not defined
This works for Cython-0.16 and earlier.
I think this was broken by ...
https://github.com/cython/cython/commit/558f4ef1c48ce091fa15b9319eb0f92cd4758f09
This patch for ModuleNode.generate_type_import_call seems to fix it:
--- a/Cython/Compiler/ModuleNode.py
+++ b/Cython/Compiler/ModuleNode.py
@@ -2281,7 +2281,6 @@ class ModuleNode(Nodes.Node, Nodes.BlockNode):
module_name = '__Pyx_BUILTIN_MODULE_NAME'
if type.name in Code.non_portable_builtins_map:
condition, replacement =
Code.non_portable_builtins_map[type.name]
-code.putln("#if %s" % condition)
if objstruct in Code.basicsize_builtins_map:
# Some builtin types have a tp_basicsize which differs from
sizeof(...):
sizeof_objstruct = Code.basicsize_builtins_map[objstruct]
Thanks,
--
Bob
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
[Cython] Hitting gcc 4.6 bug with Cython 0.17 and pandas
This issue came up earlier today. Everything works fine for me with gcc 4.6.1 and Cython 0.17, but maybe there is a bug being hit in gcc 4.6. Any debugging help would be appreciated (since this affects EC2 AMIs...) http://github.com/pydata/pandas/issues/1880 thanks, Wes ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.17 final released
Any chance we can tag the official 0.17 release in Github as well? -Brad On Sun, Sep 2, 2012 at 12:40 AM, Stefan Behnel wrote: > Robert Bradshaw, 02.09.2012 09:17: >> On Sat, Sep 1, 2012 at 11:49 PM, Stefan Behnel wrote: >>> Robert Bradshaw, 02.09.2012 06:05: I know this was brought up a couple of months ago, but we seem to be falling into a pattern of thinking about doing a bugfix release, then saying a full release is around the corner anyways, and then not actually getting it out for quite a while. I propose we start an actual bugfix branch from which we can cut minor releases at (nearly) any time, and certainly with much less hassle. Thoughts? >>> >>> +1, I'll push the master into the release branch and update the master >>> version to 0.18a0. >> >> Perhaps we should use the -pre or -post or -dev marker, as it's not >> really a marked alpha per say? > > Right, it's not going to be used in a release, so we don't need it to be > parsable. "0.18-pre" it is then. > > >> What about making a 0.17 branch, on which we can do 0.17.1, etc. if >> necessary. I don't think we're to the point of needing to backport our >> bugfixes to previous releases, but that will make things clearer. When >> the 0.18 series is ready, we can make a new branch and work on the >> release from there (possibly merging in master frequently, but not as >> a requirement). Alternatively name it bugfix and let it be regularly >> merged into main, but we can cut minor releases from it. (Release is a >> bit ambiguous as to its relationship to the other branches). > > Ok, "0.17" then. > > Stefan > > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.17 final released
First, congratulations and thanks for keeping such an important project moving forward!! On Sun, Sep 2, 2012 at 12:17 AM, Robert Bradshaw wrote: > > What about making a 0.17 branch, on which we can do 0.17.1, etc. if > necessary. I don't think we're to the point of needing to backport our > bugfixes to previous releases, but that will make things clearer. When > the 0.18 series is ready, we can make a new branch and work on the > release from there (possibly merging in master frequently, but not as > a requirement). Alternatively name it bugfix and let it be regularly > merged into main, but we can cut minor releases from it. (Release is a > bit ambiguous as to its relationship to the other branches). In case it's of any use to you guys, feel free to grab our tools for that; we follow precisely that pattern and we're just about to cut a backports-only 0.13.1 release soon: https://github.com/ipython/ipython/blob/master/tools/backport_pr.py Min wrote this tool and from what he tells me, it has really minimized the overhead of keeping a clean backports-only branch available for release. Cheers, f ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
