I vote for using the raw Python/C API. I've written a couple of PyCXX
extensions and whilst it is mostly convenient, PyCXX doesn't support the
use of numpy arrays so for them you have to use the Python/C API. This
means dealing with the reference counting yourself for numpy arrays;
extending this
On 12/03/2012 04:07 AM, Ian Thomas wrote:
I vote for using the raw Python/C API. I've written a couple of PyCXX
extensions and whilst it is mostly convenient, PyCXX doesn't support
the use of numpy arrays so for them you have to use the Python/C API.
This means dealing with the reference coun
On Sat, Dec 1, 2012 at 6:44 AM, Michiel de Hoon
>
> Since the Python/C glue code is modified only very rarely, there may not be
> a need for regenerating the Python/C glue code by developers or users from a
> Cython source code.
True.
> In addition, it is much easier to maintain the Python/C
On 12/03/2012 01:12 PM, Chris Barker - NOAA Federal wrote:
> This argues against making the Cython source code a part of the matplotlib
> codebase.
>
> huh? are you suggesting that we use Cython to generate the glue, then
> hand-maintain that glue? I think that is a really, rally bad idea --
> gen
On Mon, Dec 3, 2012 at 11:59 AM, Michael Droettboom wrote:
>>> but some of that complexity could be reduced by using Numpy arrays in place
>>> of the
>>> image buffer types that each of them contain
>> OR Cython arrays and/or memoryviews -- this is indeed a real strength of
>> Cython.
>
> Sure,
On Mon, Dec 3, 2012 at 8:24 PM, Chris Barker - NOAA Federal
wrote:
> On Mon, Dec 3, 2012 at 11:59 AM, Michael Droettboom wrote:
>> so there
>> are types in libpng, for example, that we don't actually know the size
>> of. They are different on different platforms. In C, you just include
>> the h
On Mon, Dec 3, 2012 at 2:21 PM, Nathaniel Smith wrote:
> For the file handle, I would just write
>
> cdef FILE *fp = fdopen(file_obj.fileno(), "w")
>
> and be done with it. This will work with any version of Python etc.
yeah, that makes sense -- though what if you want to be able to
read_to/wri
On Mon, Dec 3, 2012 at 12:24 PM, Chris Barker - NOAA Federal
wrote:
but some of that complexity could be reduced by using Numpy arrays in place
>> It would at least make this a more fair comparison to have the Cython
>> code as Cythonic as possible. However, I couldn't find any ways around
On Mon, Dec 3, 2012 at 11:50 PM, Chris Barker - NOAA Federal
wrote:
> On Mon, Dec 3, 2012 at 2:21 PM, Nathaniel Smith wrote:
>> For the file handle, I would just write
>>
>> cdef FILE *fp = fdopen(file_obj.fileno(), "w")
>>
>> and be done with it. This will work with any version of Python etc.
On Mon, Dec 3, 2012 at 4:16 PM, Nathaniel Smith wrote:
> Yeah, this is a general problem with the Python file API, trying to
> hook it up to stdio is not at all an easy thing. A better version of
> this code would skip that altogether like:
>
> cdef void write_to_pyfile(png_structp s, png_bytep d
On 2012/12/03 4:54 AM, Michael Droettboom wrote:
> I think Cython is well suited to writing new algorithmic code to speed
> up hot spots in Python code. I don't think it's as well suited as glue
> between C and Python -- that was not a main goal of the original Pyrex
> project, IIRC. It feels kin
11 matches
Mail list logo
