Jason Madden | 9 Oct 18:04 2015
Gravatar

[Cython] Bug - PyPy tuple leak in __Pyx_PyObject_CallOneArg?

Hello,

I'm one of the maintainers of the gevent concurrency library, which has recently been ported to run on PyPy.
Under PyPy, a small portion of the code is compiled with Cython in order to get the desired atomic semantics
(specifically, a semaphore class). We recently had a user report an easily reproducible leak of tuples of
one element. Tracking it down, it appears that __Pyx_PyObject_CallOneArg creates a new tuple under
PyPy, but neglects to free it. This was tested with Cython 0.23.3 and PyPy 2.6.1.

Our Cython code contained a loop like this, and every iteration of the loop leaked a tuple:

    for link in links:
        link(self)

The C output for that last line looked like this:

    __Pyx_PyObject_CallOneArg(__pyx_t_10, ((PyObject *)__pyx_v_self));...

And, under PyPy, the implementation of __Pyx_PyObject_CallOneArg is different than it is under CPython.
Specifically, with Cython 0.23.3 this is the code:

    #if CYTHON_COMPILING_IN_CPYTHON
    ...
    #else
    static CYTHON_INLINE PyObject* __Pyx_PyObject_CallOneArg(PyObject *func, PyObject *arg) {
        PyObject* args = PyTuple_Pack(1, arg);
        return (likely(args)) ? __Pyx_PyObject_Call(func, args, NULL) : NULL;
    }
    #endif

PyTuple_Pack is documented as returning a new reference
(Continue reading)

Stephen LARROQUE | 8 Oct 16:35 2015
Picon

Re: [Cython] cython-devel Digest, Vol 57, Issue 5

Hello Masood,

I can only answer the second issue. You need to explicitly include the *.pyx files in your MANIFEST.in, because else this .pyx files aren't automatically managed by the distutils package so it doesn't know it has to add the .pyx files.

I have recently packaged two libraries, with different hierarchy layouts, so you can maybe use one of them as an example to fix your packaging:

First project with a usual package structure:

Second project with a flatout structure:

The commands I use to locally build the package are:

python setup.py sdist --formats=gztar,zip bdist_wininst --plat-name=win32
python setup.py sdist bdist_egg bdist_wheel --plat-name=win32

If your packaging config is correct, you should see the .pyx files in those builds.

And to build all other formats and upload to pypi, I use the python library Twine:

twine upload dist/*

Hope this can help you.

Best regards,
Stephen Larroque


2015-10-08 12:00 GMT+02:00 <cython-devel-request-+ZN9ApsXKcEdnm+yROfE0A@public.gmane.org>:
Send cython-devel mailing list submissions to
        cython-devel-+ZN9ApsXKcEdnm+yROfE0A@public.gmane.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://mail.python.org/mailman/listinfo/cython-devel
or, via email, send a message with subject or body 'help' to
        cython-devel-request-+ZN9ApsXKcEdnm+yROfE0A@public.gmane.org

You can reach the person managing the list at
        cython-devel-owner-+ZN9ApsXKcEdnm+yROfE0A@public.gmane.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cython-devel digest..."


Today's Topics:

   1. Cython coverage and multiple projects (Masood Malekghassemi)


----------------------------------------------------------------------

Message: 1
Date: Wed, 7 Oct 2015 16:06:01 -0700
From: Masood Malekghassemi <atash <at> google.com>
To: cython-devel-+ZN9ApsXKcEdnm+yROfE0A@public.gmane.org
Subject: [Cython] Cython coverage and multiple projects
Message-ID:
        <CALweS8f=xeQfhmydXR5C70mbO1=1hibmsTgBPuvCuiUEqE=g8w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Content-Type: text/plain; charset="utf-8"

I'd asked this of Robert Bradshaw earlier and was pointed in this direction
(specifically towards Stefan), so here goes!

I'm having trouble with getting Cython to play nicely with the coverage.py
tool via the Cython.Coverage plug-in.

We have tests that are running from a different setup.py project than the
one which contains the Cython files (the projects respectively being for
the duration of this discussion the 'tests' project and the 'source'
project). The generated coverage file contains the line data for individual
.pyx files, but the paths of the .pyx files themselves *within* the
.coverage file appear to be rooted in the tests project rather than the
site-packages folder in which the source project's files were installed
(i.e. paths that never exist throughout the edit-build-test cycle).

After editing the .coverage file manually to point to the source project
directory, coverage.py reports that the .pyx files are not python files and
errors out... but the .coveragerc file contains the plug-in module via
`[run]\n plugins = Cython.Coverage`, so I'd have expected the Cython
coverage.py plug-in to catch those files and handle them instead of letting
the rest of coverage.py get confused over them.

Furthermore, this is against the 4.0 coverage.py release rather than the
4.0b2 coverage.py release (which appears to be the version against which
the latest edit to the Cython code base was made). I don't see any API
differences between the two in the plug-ins, but I might have missed
something so maybe that's relevant.

A secondary issue: the .pyx files are never copied over to the installation
directory, so even if the paths were 'correct' (with respect to being
copied into the site-packages folder or being accessible via developer mode
pip-installs), they wouldn't be found. This seems like it wouldn't
necessarily be an issue from a cursory glance at the source code as the
file tracer in the Cython coverage.py plug-in appears to spit out blank
lines in such a scenario.

Complicating matters further, we're running the tests through pytest. That
said, I've given up on trying to get pytest-cov to play nicely with this
until I can get a manual invocation of `coverage report ...` to produce
output describing the .pyx files.

Thanks for reading this far. Got any pointers?


----------------------------------------------------------------
Context: https://github.com/soltanmm/grpc/tree/cy-wip/src/python
Basic steps to run the tests:

   - cd $GRPC_REPOSITORY_ROOT
   - make
   - CONFIG=opt ./tools/run_tests/build_python.sh 2.7
   - CONFIG=opt PYVER=2.7 ./run_tests/run_python.sh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20151007/11793594/attachment-0001.html>

------------------------------

Subject: Digest Footer

_______________________________________________
cython-devel mailing list
cython-devel-+ZN9ApsXKcEdnm+yROfE0A@public.gmane.org
https://mail.python.org/mailman/listinfo/cython-devel


------------------------------

End of cython-devel Digest, Vol 57, Issue 5
*******************************************

<div>
<div dir="ltr">Hello Masood,<div><br></div>
<div>I can only answer the second issue. You need to explicitly include the *.pyx files in your MANIFEST.in, because else this .pyx files aren't automatically managed by the distutils package so it doesn't know it has to add the .pyx files.</div>
<div><br></div>
<div>I have recently packaged two libraries, with different hierarchy layouts, so you can maybe use one of them as an example to fix your packaging:</div>
<div><br></div>
<div>First project with a usual package structure:</div>
<div>
<a href="https://github.com/lrq3000/unireedsolomon/blob/master/MANIFEST.in">https://github.com/lrq3000/unireedsolomon/blob/master/MANIFEST.in</a><br>
</div>
<div><a href="https://github.com/lrq3000/unireedsolomon/blob/master/setup.py">https://github.com/lrq3000/unireedsolomon/blob/master/setup.py</a></div>
<div><br></div>
<div>Second project with a flatout structure:</div>
<div>
<a href="https://github.com/lrq3000/reedsolomon/blob/master/MANIFEST.in">https://github.com/lrq3000/reedsolomon/blob/master/MANIFEST.in</a><br>
</div>
<div><a href="https://github.com/lrq3000/reedsolomon/blob/master/setup.py">https://github.com/lrq3000/reedsolomon/blob/master/setup.py</a></div>
<div><br></div>
<div>The commands I use to locally build the package are:</div>
<div><br></div>
<div>
<div>python setup.py sdist --formats=gztar,zip bdist_wininst --plat-name=win32</div>
<div>python setup.py sdist bdist_egg bdist_wheel --plat-name=win32</div>
</div>
<div><br></div>
<div>If your packaging config is correct, you should see the .pyx files in those builds.</div>
<div><br></div>
<div>And to build all other formats and upload to pypi, I use the python library Twine:</div>
<div><br></div>
<div>twine upload dist/*<br>
</div>
<div><br></div>
<div>Hope this can help you.</div>
<div><br></div>
<div>Best regards,</div>
<div>Stephen Larroque</div>
<div><br></div>
</div>
<div class="gmail_extra">
<br><div class="gmail_quote">2015-10-08 12:00 GMT+02:00  <span dir="ltr">&lt;<a href="mailto:cython-devel-request@..." target="_blank">cython-devel-request@...</a>&gt;</span>:<br><blockquote class="gmail_quote">Send cython-devel mailing list submissions to<br>
&nbsp; &nbsp; &nbsp; &nbsp; <a href="mailto:cython-devel@...">cython-devel@...</a><br><br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
&nbsp; &nbsp; &nbsp; &nbsp; <a href="https://mail.python.org/mailman/listinfo/cython-devel" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/cython-devel</a><br>
or, via email, send a message with subject or body 'help' to<br>
&nbsp; &nbsp; &nbsp; &nbsp; <a href="mailto:cython-devel-request <at> python.org">cython-devel-request@...</a><br><br>
You can reach the person managing the list at<br>
&nbsp; &nbsp; &nbsp; &nbsp; <a href="mailto:cython-devel-owner@...">cython-devel-owner@...</a><br><br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of cython-devel digest..."<br><br><br>
Today's Topics:<br><br>
&nbsp; &nbsp;1. Cython coverage and multiple projects (Masood Malekghassemi)<br><br><br>
----------------------------------------------------------------------<br><br>
Message: 1<br>
Date: Wed, 7 Oct 2015 16:06:01 -0700<br>
From: Masood Malekghassemi &lt;<a href="mailto:atash@...">atash <at> google.com</a>&gt;<br>
To: <a href="mailto:cython-devel@...">cython-devel@...</a><br>
Subject: [Cython] Cython coverage and multiple projects<br>
Message-ID:<br>
&nbsp; &nbsp; &nbsp; &nbsp; &lt;CALweS8f=xeQfhmydXR5C70mbO1=1hibmsTgBPuvCuiUEqE=<a href="mailto:g8w@...">g8w@...</a>&gt;<br>
Content-Type: text/plain; charset="utf-8"<br><br>
I'd asked this of Robert Bradshaw earlier and was pointed in this direction<br>
(specifically towards Stefan), so here goes!<br><br>
I'm having trouble with getting Cython to play nicely with the coverage.py<br>
tool via the Cython.Coverage plug-in.<br><br>
We have tests that are running from a different setup.py project than the<br>
one which contains the Cython files (the projects respectively being for<br>
the duration of this discussion the 'tests' project and the 'source'<br>
project). The generated coverage file contains the line data for individual<br>
.pyx files, but the paths of the .pyx files themselves *within* the<br>
.coverage file appear to be rooted in the tests project rather than the<br>
site-packages folder in which the source project's files were installed<br>
(i.e. paths that never exist throughout the edit-build-test cycle).<br><br>
After editing the .coverage file manually to point to the source project<br>
directory, coverage.py reports that the .pyx files are not python files and<br>
errors out... but the .coveragerc file contains the plug-in module via<br>
`[run]\n plugins = Cython.Coverage`, so I'd have expected the Cython<br>
coverage.py plug-in to catch those files and handle them instead of letting<br>
the rest of coverage.py get confused over them.<br><br>
Furthermore, this is against the 4.0 coverage.py release rather than the<br>
4.0b2 coverage.py release (which appears to be the version against which<br>
the latest edit to the Cython code base was made). I don't see any API<br>
differences between the two in the plug-ins, but I might have missed<br>
something so maybe that's relevant.<br><br>
A secondary issue: the .pyx files are never copied over to the installation<br>
directory, so even if the paths were 'correct' (with respect to being<br>
copied into the site-packages folder or being accessible via developer mode<br>
pip-installs), they wouldn't be found. This seems like it wouldn't<br>
necessarily be an issue from a cursory glance at the source code as the<br>
file tracer in the Cython coverage.py plug-in appears to spit out blank<br>
lines in such a scenario.<br><br>
Complicating matters further, we're running the tests through pytest. That<br>
said, I've given up on trying to get pytest-cov to play nicely with this<br>
until I can get a manual invocation of `coverage report ...` to produce<br>
output describing the .pyx files.<br><br>
Thanks for reading this far. Got any pointers?<br><br><br>
----------------------------------------------------------------<br>
Context: <a href="https://github.com/soltanmm/grpc/tree/cy-wip/src/python" rel="noreferrer" target="_blank">https://github.com/soltanmm/grpc/tree/cy-wip/src/python</a><br>
Basic steps to run the tests:<br><br>
&nbsp; &nbsp;- cd $GRPC_REPOSITORY_ROOT<br>
&nbsp; &nbsp;- make<br>
&nbsp; &nbsp;- CONFIG=opt ./tools/run_tests/build_python.sh 2.7<br>
&nbsp; &nbsp;- CONFIG=opt PYVER=2.7 ./run_tests/run_python.sh<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: &lt;<a href="http://mail.python.org/pipermail/cython-devel/attachments/20151007/11793594/attachment-0001.html" rel="noreferrer" target="_blank">http://mail.python.org/pipermail/cython-devel/attachments/20151007/11793594/attachment-0001.html</a>&gt;<br><br>
------------------------------<br><br>
Subject: Digest Footer<br><br>
_______________________________________________<br>
cython-devel mailing list<br><a href="mailto:cython-devel@...">cython-devel@...</a><br><a href="https://mail.python.org/mailman/listinfo/cython-devel" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/cython-devel</a><br><br><br>
------------------------------<br><br>
End of cython-devel Digest, Vol 57, Issue 5<br>
*******************************************<br>
</blockquote>
</div>
<br>
</div>
</div>

[Cython] Cython coverage and multiple projects

I'd asked this of Robert Bradshaw earlier and was pointed in this direction (specifically towards Stefan), so here goes!

I'm having trouble with getting Cython to play nicely with the coverage.py tool via the Cython.Coverage plug-in.

We have tests that are running from a different setup.py project than the one which contains the Cython files (the projects respectively being for the duration of this discussion the 'tests' project and the 'source' project). The generated coverage file contains the line data for individual .pyx files, but the paths of the .pyx files themselves within the .coverage file appear to be rooted in the tests project rather than the site-packages folder in which the source project's files were installed (i.e. paths that never exist throughout the edit-build-test cycle).

After editing the .coverage file manually to point to the source project directory, coverage.py reports that the .pyx files are not python files and errors out... but the .coveragerc file contains the plug-in module via `[run]\n plugins = Cython.Coverage`, so I'd have expected the Cython coverage.py plug-in to catch those files and handle them instead of letting the rest of coverage.py get confused over them.

Furthermore, this is against the 4.0 coverage.py release rather than the 4.0b2 coverage.py release (which appears to be the version against which the latest edit to the Cython code base was made). I don't see any API differences between the two in the plug-ins, but I might have missed something so maybe that's relevant.

A secondary issue: the .pyx files are never copied over to the installation directory, so even if the paths were 'correct' (with respect to being copied into the site-packages folder or being accessible via developer mode pip-installs), they wouldn't be found. This seems like it wouldn't necessarily be an issue from a cursory glance at the source code as the file tracer in the Cython coverage.py plug-in appears to spit out blank lines in such a scenario.

Complicating matters further, we're running the tests through pytest. That said, I've given up on trying to get pytest-cov to play nicely with this until I can get a manual invocation of `coverage report ...` to produce output describing the .pyx files.

Thanks for reading this far. Got any pointers?


----------------------------------------------------------------
Basic steps to run the tests:
  • cd $GRPC_REPOSITORY_ROOT
  • make
  • CONFIG=opt ./tools/run_tests/build_python.sh 2.7
  • CONFIG=opt PYVER=2.7 ./run_tests/run_python.sh
<div><div dir="ltr">
<div><span>I'd asked this of Robert Bradshaw earlier and was pointed in this direction (specifically towards Stefan), so here goes!</span></div>
<div><span><br></span></div>
<div>
<span>I'm having trouble with getting Cython to play nicely with the coverage.py tool via the Cython.Coverage plug-in.</span><br>
</div>
<div><br></div>
<div>We have tests that are running from a different setup.py project than the one which contains the Cython files (the projects respectively being for the duration of this discussion the 'tests' project and the 'source' project). The generated coverage file contains the line data for individual .pyx files, but the paths of the .pyx files themselves&nbsp;within&nbsp;the .coverage file appear to be rooted in the tests project rather than the site-packages folder in which the source project's files were installed (i.e. paths that never exist throughout the edit-build-test cycle).<div><br></div>
<div>After editing the .coverage file manually to point to the source project directory, coverage.py reports that the .pyx files are not python files and errors out... but the .coveragerc file contains the plug-in module via `[run]\n plugins = Cython.Coverage`, so I'd have expected the Cython coverage.py plug-in to catch those files and handle them instead of letting the rest of coverage.py get confused over them.</div>
<div><br></div>
<div>Furthermore, this is against the 4.0 coverage.py release rather than the 4.0b2 coverage.py release (which appears to be the version against which the latest edit to the Cython code base was made). I don't see any API differences between the two in the plug-ins, but I might have missed something so maybe that's relevant.<br><div><br></div>
<div>A secondary issue: the .pyx files are never copied over to the installation directory, so even if the paths were 'correct' (with respect to being copied into the site-packages folder or being accessible via developer mode pip-installs), they wouldn't be found. This seems like it wouldn't necessarily be an issue from a cursory glance at the source code as the file tracer in the Cython coverage.py plug-in appears to spit out blank lines in such a scenario.</div>
</div>
<div><br></div>
<div>Complicating matters further, we're running the tests through pytest. That said, I've given up on trying to get pytest-cov to play nicely with this until I can get a manual invocation of `coverage report ...` to produce output describing the .pyx files.</div>
<div><br></div>
<div>Thanks for reading this far. Got any pointers?</div>
<div><br></div>
<div><br></div>
<div>----------------<span>----------------</span><span>----------------</span><span>----------------</span>
</div>
<div>
<div>
<span>Context:&nbsp;</span><span><a href="https://github.com/soltanmm/grpc/tree/cy-wip/src/python">https://github.com/soltanmm/grpc/tree/cy-wip/src/python</a></span>
</div>
<div><span>Basic steps to run the tests:</span></div>
<div><ul>
<li><span>cd $GRPC_REPOSITORY_ROOT</span></li>
<li><span>make</span></li>
<li>
<span>CONFIG=opt ./tools/run_tests/build_python.sh 2.7</span><br>
</li>
<li><span>CONFIG=opt PYVER=2.7 ./run_tests/run_python.sh</span></li>
</ul></div>
</div>
</div>
</div></div>
Jeroen Demeyer | 5 Oct 16:04 2015
Picon

[Cython] __dealloc__ called even if __cinit__ failed

Hello,

I'm not entirely sure if this is a feature or bug...

I noticed that, if a __cinit__ call raises an exception on an object, 
that __dealloc__ on that same object is still called.

The problem is that __cinit__ is supposed to set up the C-level 
attributes for that object. If this somehow fails, then the object isn't 
in a consistent state yet, so it makes no sense to call __dealloc__ on it.

Do you consider this a Cython bug or should I manually protect my code 
against this?

Thanks,
Jeroen.
Josh Ayers | 3 Oct 18:04 2015

[Cython] Cython 0.23.3 compiler warning with fused types

Cython devs,

Using Cython 0.23.3 and Python 3.4.3, the following Cython code:

ctypedef fused floating:
    float
    double

cpdef add_one(floating [:] array):
    cdef Py_ssize_t i
    for i in range(array.shape[0]):
        array[i] += 1.0

produces the C code below.  It raises a compiler warning because a long
is assigned to a char.

char __pyx_v_kind;
...
long __pyx_t_11;
...
__pyx_t_11 = __Pyx_PyObject_Ord(__pyx_t_8);
...
__pyx_v_kind = __pyx_t_11;

Thanks,
Josh Ayers
Lisandro Dalcin | 2 Oct 12:11 2015
Picon

[Cython] Python 3 wheels including bytecode files.

After getting AppVeyor to work, I noticed that Python 3 wheels do
include __pycache__ directory. This also happens with in OS X as well
as Linux.

I think the root of the issue resides in setup.py, in the build_ext
command class workaround that seems to be a legacy thing from the time
Cython required 2to3. BTW, in setup.py, compile_cython_modules()
follows quite a different path in Python 2 versus 3.

Unless some of you believe we should keep things that way, I'll try to
fix setup.py to be as much independent as possible of the major Python
version.

--

-- 
Lisandro Dalcin
============
Research Scientist
Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
Numerical Porous Media Center (NumPor)
King Abdullah University of Science and Technology (KAUST)
http://numpor.kaust.edu.sa/

4700 King Abdullah University of Science and Technology
al-Khawarizmi Bldg (Bldg 1), Office # 4332
Thuwal 23955-6900, Kingdom of Saudi Arabia
http://www.kaust.edu.sa

Office Phone: +966 12 808-0459
Hogan, Christopher | 30 Sep 00:03 2015
Picon

[Cython] Bug: llabs not defined in vs2008

Hello,

 

I was trying to compile numpy v1.9.2 with Visual Studio 2008 and Cython 0.23.1.  This worked fine with Cython 0.22.x, but in 0.23.1 there are some changes in Cython/Utility/TypeConversion.c that seem to cause this error:

 

mtrand.obj : error LNK2019: unresolved external symbol llabs referenced in function __pyx_pf_6mtrand_11RandomState_24 choice

 

llabs is not available in vs2008, but it ends up taking that “#elif” branch in TypeConversion.c and defining __Pyx_sst_abs to be llabs.  I was able to fix this by swapping the order of the “#elif defined (_MSC_VER) …”  block with the “#elif defined (__STDC_VERSION__) … “ block.  That probably won’t fix the problem in all cases though.

 

Thanks,

 

Chris Hogan

Scripting Tools Engineer

Scripting, Analyzers and Tools

Intel Corporation

 

<div>
<div class="WordSection1">
<p class="MsoNormal">Hello,<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">I was trying to compile numpy v1.9.2 with Visual Studio 2008 and Cython 0.23.1.&nbsp; This worked fine with Cython 0.22.x, but in 0.23.1 there are some changes in Cython/Utility/TypeConversion.c that seem to cause this error:<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal"><span>mtrand.obj : error LNK2019: unresolved external symbol llabs referenced in function __pyx_pf_6mtrand_11RandomState_24 choice<p></p></span></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">llabs is not available in vs2008, but it ends up taking that &ldquo;#elif&rdquo; branch in TypeConversion.c and defining __Pyx_sst_abs to be llabs.&nbsp; I was able to fix this by swapping the order of the &ldquo;#elif defined (_MSC_VER) &hellip;&rdquo; &nbsp;block with the &ldquo;#elif
 defined (__STDC_VERSION__) &hellip; &ldquo; block.&nbsp; That probably won&rsquo;t fix the problem in all cases though.<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Thanks,<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Chris Hogan<p></p></p>
<p class="MsoNormal">Scripting Tools Engineer<p></p></p>
<p class="MsoNormal">Scripting, Analyzers and Tools<p></p></p>
<p class="MsoNormal">Intel Corporation<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
</div>
</div>
Mirth Hickford | 27 Sep 21:30 2015
Picon

[Cython] Publish Windows wheels to PyPI

Hi Cython. Please consider publishing wheels for Windows to PyPI [1]. Wheels [2] are a package format that installs more reliably than source distributions, especially on Windows.

Meanwhile a workaround is to download wheels from Christoph Gohlke's site [3] a godsend.

<div><div dir="ltr">Hi Cython. Please consider publishing wheels for Windows to PyPI [1]. Wheels [2] are a package format that installs more reliably than source distributions, especially on Windows.<div><br></div>
<div>Meanwhile a workaround is to download wheels from&nbsp;Christoph Gohlke's site [3] a godsend.</div>
<div>
<br><div>
<div>-M</div>
<div><br></div>
<div>[1]&nbsp;<a href="https://pypi.python.org/pypi/Cython/">https://pypi.python.org/pypi/Cython/</a>
</div>
<div>[2]&nbsp;<a href="http://pythonwheels.com/">http://pythonwheels.com/</a>
</div>
<div>[3] <a href="http://www.lfd.uci.edu/~gohlke/pythonlibs/#cython">http://www.lfd.uci.edu/~gohlke/pythonlibs/#cython</a><br>
</div>
</div>
</div>
<div><br></div>
</div></div>
Yaroslav Halchenko | 21 Sep 16:26 2015
Gravatar

[Cython] ct_DEF.__test__.large_nums doctest failing in 32bit

was reported in Debian against 0.23.2 so tried blindly freshier snapshot
from 0.23.x branch and that one is no go too:

======================================================================
FAIL: large_nums (line 95) (ct_DEF.__test__)
Doctest: ct_DEF.__test__.large_nums (line 95)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/doctest.py", line 2226, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for ct_DEF.__test__.large_nums (line 95)
  File "/tmp/buildd/cython-0.23.2+git12-g2c9d175/build/work-dir/run/cpp/ct_DEF/ct_DEF.so",
line unknown line number, in large_nums (line 95)

----------------------------------------------------------------------
File "/tmp/buildd/cython-0.23.2+git12-g2c9d175/build/work-dir/run/cpp/ct_DEF/ct_DEF.so",
line ?, in ct_DEF.__test__.large_nums (line 95)
Failed example:
    print_large_number(n64)
Expected:
    -4294967295
Got:
    1

--

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience     http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        
Nathaniel Smith | 14 Sep 14:33 2015

[Cython] Is it easy to do an "AST grep" of Cython code?

I have a few hundred files worth of Cython code, and I'd like to find
all instances where a variable/expression has a certain cdef class
type. (More specifically, I'd like to find all accesses to the cdef
fields of a particular cdef class, but even just finding all 'cdef
MYTYPE x" and "<MYTYPE>x" statements would probably get me pretty
close.) Is there any easy way to do this?

(The files are "every cython file on github or searchcode.com that
mentions the word "ufunc"", and I'm trying to find code that does
direct field access to the internals of the PyUFuncObject struct.)

--

-- 
Nathaniel J. Smith -- http://vorpus.org
Jelle Zijlstra | 13 Sep 21:00 2015
Picon

[Cython] CPython incompatibility in string literal concatenation

While implementing PEP 498 I found a minor incompatibility between
CPython and Cython: CPython lets you concatenate u-prefixed and
non-prefixed string literals, while Cython throws an error.

jelle <at> devjelle:~/cython$ cat concat.py
print(u'foo' 'bar')

jelle <at> devjelle:~/cython$ python concat.py
foobar
jelle <at> devjelle:~/cython$ cython concat.py

Error compiling Cython file:
------------------------------------------------------------
...
print(u'foo' 'bar')
            ^
------------------------------------------------------------

concat.py:1:13: Cannot mix string literals of different types,
expected u'', got ''

I tried both CPython 2.7 and 3.5. The documentation at
https://docs.python.org/2/reference/lexical_analysis.html#string-literal-concatenation
is ambiguous as to whether this behavior is intentional.

As part of implementing PEP 498, I can make Cython's behavior match
CPython's, unless there's a good reason to keep the incompatibility.

Gmane