Re: [matplotlib-devel] Experiments in removing/replacing PyCXX
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 to do the reference counting for all python objects is not onerous. Dealing with object lifetimes is bread-and-butter work for C/C++ developers. I have never used Cython, but to me the code looks like an inelegant combination of Python, C/C++ and some Cython-specific stuff. I can see the advantage of this approach for small sections of code, but I have strong reservations about using it for complicated modules that have extensive use of templated code and/or Standard Template Library collections (mpl has examples of both of these). I agree that Cython opens us up to a larger body of contributors, but I don't think that this is necessarily a good thing. I think this really means opens us up to a larger body of Python/Cython contributors, and is a view expressed from the Python side of the fence and has the wrong emphasis. I am primarily a C++ developer is a sea of Python developers, and rather than encourage other Python contributors to dip their toes into C/C++ via Cython I think we should be encouraging C/C++ contributors to do what they do best. We only need a few C/C++ developers if we allow them to use their skills in their preferred way, and they are used to interfacing to legacy APIs and dealing with object lifetimes. OK, cards on the table. If we wanted to switch all of our PyCXX modules to use the raw Python/C API, I would happily take on some of the burden for making the changes and ongoing maintenance of such modules. Particularly if, in return, I get some help with my sometimes substandard Python! If we go down the Cython route I couldn't make this offer; would our many Cython advocates take on the responsibility of changing and maintaining my C++ code in this scenario? Ian Thomas -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experiments in removing/replacing PyCXX
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 counting yourself for numpy arrays; extending this to do the reference counting for all python objects is not onerous. Dealing with object lifetimes is bread-and-butter work for C/C++ developers. That matches my experience quite well. I have never used Cython, but to me the code looks like an inelegant combination of Python, C/C++ and some Cython-specific stuff. I can see the advantage of this approach for small sections of code, but I have strong reservations about using it for complicated modules that have extensive use of templated code and/or Standard Template Library collections (mpl has examples of both of these). Even for C libraries like libpng, which requires use of C function callbacks for some things, Cython is more convoluted, particularly when things go wrong and require debugging. (Running gdb over generated Cython code is not fun!) And in my view, writing code like that requires a pretty deep understanding of the Python/C API, C itself, and the rather complex transformations that Cython performs. Writing directly to the Python/C API only requires knowledge of the first two. And there's a large body of books/tutorials/debuggers/tools for C that don't really have equivalents for Cython. I agree that Cython opens us up to a larger body of contributors, but I don't think that this is necessarily a good thing. I think this really means opens us up to a larger body of Python/Cython contributors, and is a view expressed from the Python side of the fence and has the wrong emphasis. I am primarily a C++ developer is a sea of Python developers, and rather than encourage other Python contributors to dip their toes into C/C++ via Cython I think we should be encouraging C/C++ contributors to do what they do best. We only need a few C/C++ developers if we allow them to use their skills in their preferred way, and they are used to interfacing to legacy APIs and dealing with object lifetimes. 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 kind of tacked on and not a very good fit to the problem. Most of the work to remove PyCXX use in matplotlib is either wrapping third-party libraries (where Cython doesn't really shine), or wrapping C/C++ code in our own tree that's already well-tested and vetted, and I wouldn't propose rewriting that in Cython. I'm only really considering rewriting the Python-to-C interface layer. OK, cards on the table. If we wanted to switch all of our PyCXX modules to use the raw Python/C API, I would happily take on some of the burden for making the changes and ongoing maintenance of such modules. Particularly if, in return, I get some help with my sometimes substandard Python! If we go down the Cython route I couldn't make this offer; would our many Cython advocates take on the responsibility of changing and maintaining my C++ code in this scenario? That's a good way to look at this. I was definitely hoping that moving to Cython might open us up to more developers, but at the end of the day, the chosen tool should be the one preferred by those doing the work. Maybe rather than asking "if we switched to using Cython, would more participate", I should be asking "among those that can participate in removing the PyCXX dependency, what is the preferred approach?" Cheers, Mike -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experiments in removing/replacing PyCXX
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 glue code than to > write it from scratch. Once you have the Python/C glue code, it's relatively > straightforward to modify it by looking at the existing Python/C glue code. > not so true -- getting reference counting right, etc is difficult -- I suppose once the glue code is robust, and all you are changing is a bit of API to the C, maybe > > 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 -- generated code is ugly and hard to maintain, it is not designed to be human-readable, and we wouldn't get the advantages of bug-fixes further development in Cython. So -- if you use Cython, you want to keep using, and theat means the Cython source IS the source. I agree that it's a good idea to ship the generated code as well, so that no one that is not touching the Cython has to generate. Other than the slight mess from generated files showing up in diffs, etc, this really works just fine. Any reason MPL couldn't continue with EXACTLY the same approach now used with C_XX -- it generates code as well, yes? Michael Droettboom wrote: > For the PNG extension specifically, it was creating callbacks that can > be called from C and the setjmp magic that libpng requires. I think > it's possible to do it, but I was surprised at how non-obvious those > pieces of Cython were. I was really hoping by creating this experiment > that a Cython expert would step up and show the way ;) Did you not get the support you expected from the cython list? Anyway, there's no reason you can't keep stuff in C that's easier in C (or did C_XX make this easy?). I think making basic callbacks is actually pretty straightforward, but In don't know about the setjmp magic (I have no idea hat that means!). > The Agg backend has more C++-specific challenges, particularly > instantiating very complex template expressions -- I'm guessing you'd do the complex template stuff in C++ -- and let Cython see a more traditional static API. > 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. > The Cython version isn't that much shorter than the C++ version. I think some things make sense to keep in C++, though I do see a fair bit of calls (in the C++) to the python API -- I'm surprised there isn't much code advantage, but anyway, the goal is more robust/easier to maintain, which may correlate with code-size, but not completely. > These declarations aren't exact matches to what one would find in the header > file(s) >because Cython doesn't support exact-width data types etc. It does support the C99 fixed-width integer types: from libc.stdint cimport int16_t, int32_t, Or are you talking about something else? > I'm not sure why some of the Python/C API calls I needed were not defined in > Cython's include wrappers. I suspect that's an oversight -- for the most part, stuff has been added as it's needed. One other note -- from a quick glance at your Cython code, it looks like you did almost everything is Cython-that-will-compile-to-pure-C -- i.e. a lot of calls to the CPython API. But the whole point of Cython is that it makes those calls for you. So you can do type checking, and switching on types, and calling np.asarray(), etc, etc, etc, in Python, without calling the CPython api yourself. I know nothing of the PNG API, and am pretty week on the CPython API (and C for that matter), but I it's likely that the Cython code you've written could be much simplified. > Once things compiled, due to my own mistake, calling the function segfaulted. > Debugging > that segfault in gdb required, again, wading through the generated code. > Using gdb on > hand-written code is *much* nicer. for sure -- there is a plug-in/add-on/something for using gdb on Cython code -- I haven't used it but I imagine it would help. Ian Thomas wrote: > I have never used Cython, but to me the code looks like an inelegant > combination of > Python,C/C++ and some Cython-specific stuff. well, yes, it is that! > I can see the advantage of this approach for small sections of code, but I > have strong > reservations about using it for complicated modules that have > extensive use of > templated code and/or Standard Template Library collections (mpl has examples > of > both of these). So far, I've found that Cython is good for: - The simple stuff -- basic loops through numpy arrays, etc. - wrapping/calling more complex C or C
Re: [matplotlib-devel] Experiments in removing/replacing PyCXX
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 -- > generated code is ugly and hard to maintain, it is not designed to be > human-readable, and we wouldn't get the advantages of bug-fixes > further development in Cython. > > So -- if you use Cython, you want to keep using, and theat means the > Cython source IS the source. I agree that it's a good idea to ship the > generated code as well, so that no one that is not touching the Cython > has to generate. Other than the slight mess from generated files > showing up in diffs, etc, this really works just fine. I agree with this approach. > > Any reason MPL couldn't continue with EXACTLY the same approach now > used with C_XX -- it generates code as well, yes? No -- PyCXX is just C++. Its killer feature is that it provides a fairly thin layer around the Python C/API that does implicit reference counting through the use of C++ constructors and destructors. I actually think it's a really elegant approach to the problem. The downside we're running into is that it's barely maintained, so using vanilla upstream as provided by packagers is not viable. An alternative to all of this discussion is to fork PyCXX and release as needed. The maintenance required is primarily when new versions of Python are released, so it wouldn't necessarily be a huge undertaking. However, I know some are reluctant to use a relatively unused tool. > > Michael Droettboom wrote: > >> For the PNG extension specifically, it was creating callbacks that can >> be called from C and the setjmp magic that libpng requires. I think >> it's possible to do it, but I was surprised at how non-obvious those >> pieces of Cython were. I was really hoping by creating this experiment >> that a Cython expert would step up and show the way ;) > Did you not get the support you expected from the cython list? Anyway, > there's no reason you can't keep stuff in C that's easier in C (or did > C_XX make this easy?). The support has been adequate, but the solutions aren't always an improvement over raw Python/C API (not just in terms of lines of code but in terms of the number of layers of abstraction and "magic" between the coder and what actually happens). > I think making basic callbacks is actually > pretty straightforward, but In don't know about the setjmp magic (I > have no idea hat that means!). It turned out to be not terrible once I figured out the correct incantation. > >> The Agg backend has more C++-specific challenges, particularly >> instantiating very complex template expressions -- > I'm guessing you'd do the complex template stuff in C++ -- and let > Cython see a more traditional static API. Agreed -- I'm really only considering replacing the glue code provided by PyCXX, not the whole thing. matplotlib's C/C++ code has been around for a while and has been fairly vetted at this point, so I don't think a wholesale rewrite makes sense. > >> 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, but when we return to Python, they should be Numpy arrays which have more methods etc. -- or am I missing something? >> The Cython version isn't that much shorter than the C++ version. > I think some things make sense to keep in C++, though I do see a fair > bit of calls (in the C++) to the python API -- I'm surprised there > isn't much code advantage, but anyway, the goal is more robust/easier > to maintain, which may correlate with code-size, but not completely. > >> These declarations aren't exact matches to what one would find in the header >> file(s) >because Cython doesn't support exact-width data types etc. > It does support the C99 fixed-width integer types: > > from libc.stdint cimport int16_t, int32_t, > > Or are you talking about something else? The problem is that Cython can't actually read the C header, 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 header. In Cython, I'd have to determine the size of the types in a pre-compilation step, or manually determine their sizes and hard code them for the platforms we care about. > >> I'm not sure why some of the Python/C API calls I needed were not defined in >> Cython's include wrappers. > I suspect that's an oversight -- for the most part, stuff has been > added as it's needed. > > One other note -- from a quick glance at your Cython code, it looks > like you did almost everything is Cython-that-will-compile-to-pure-C > -- i.e. a lot of calls to the CPython API. But the whole point of > C
Re: [matplotlib-devel] Experiments in removing/replacing PyCXX
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, but when we return to Python, they should be Numpy arrays which > have more methods etc. -- or am I missing something? Cython makes it really easy to switch between ndarrays and memoryviews, etc -- it's a question of what you want to work with in your code, so you have write a function that takes numpy arrays and returns numpy arrays, but uses a memoryview internally (and passes to C code that way). But I'm not an expert on this, I'mve found that I'm either doing simplestuff where using numpy arrays directly works fine, or passing the pointer to the data array off to C: def a_function_to_call_C( cnp.ndarray[double, ndim=2, mode="c" ] in_array ): """ calls the_c_function, altering the array in-place """ cdef int m, n m = in_array.size[0] m = in_array.size[1] the_c_function( &in_array[0], m, n ) >> It does support the C99 fixed-width integer types: >> from libc.stdint cimport int16_t, int32_t, >> > The problem is that Cython can't actually read the C header, yeah, this is a pity. There has been some work on auto-generating Cython from C headers, though nothing mature. For my work, I've been considering writing some simple pyd-generating code, just to make sure my data types are inline with the C++ as it may change. > 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 header. In Cython, I'd have to determine the size of the types in a > pre-compilation step, or manually determine their sizes and hard code > them for the platforms we care about. yeah -- this is a tricky problem, however, I think you can follow what you'd do in C -- i.e. presumable the header define their own data types: png_short or whatever. The actually definition is filled in by the pre-processor. So I wonder if you can declare those types in Cython, then have it write C code that uses those types, and it all gets cleared up at compile time -- maybe. The key is that when you declare stuff in Cython, that declaration is used to determine how to write the C code, I don't think the declarations themselves are translated. > 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 > using these particular APIs -- other than the Numpy stuff which probably > does have a more elegant solution in the form of Cython arrays and > memory views. yup -- that's what I noticed right away -- I"m note sure it there is easier handling of file handles. > True. We do have two categories of stuff using PyCXX in matplotlib: > things that (primarily) wrap third-party C/C++ libraries, and things > that are actually doing algorithmic heavy lifting. It's quite possible > we don't want the same solution for all. And I'm not sure the wrappers all need to be written the same way, either. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experiments in removing/replacing PyCXX
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 header. In Cython, I'd have to determine the size of the types in a >> pre-compilation step, or manually determine their sizes and hard code >> them for the platforms we care about. > > yeah -- this is a tricky problem, however, I think you can follow what > you'd do in C -- i.e. presumable the header define their own data > types: png_short or whatever. The actually definition is filled in by > the pre-processor. So I wonder if you can declare those types in > Cython, then have it write C code that uses those types, and it all > gets cleared up at compile time -- maybe. The key is that when you > declare stuff in Cython, that declaration is used to determine how to > write the C code, I don't think the declarations themselves are > translated. Yeah, this isn't an issue in Cython, it's a totally standard thing (though perhaps not well documented). When you write cdef extern from "png.h": ctypedef int png_short or whatever, what you are saying is "the C compiler knows about a type called png_short, which acts in an int-like fashion, so Cython, please use your int rules when dealing with it". So this means that Cython will know that if you return a png_short from a python function, it should insert a call to PyInt_FromLong (or maybe PyInt_FromSsize_t? -- cython worries about these things so I don't have to). But Cython only takes care of the Python<->C interface. It will leave the C compiler to actually allocate the appropriate memory for png_shorts, perform C arithmetic, coerce a png_short into a 'long' when necessary, etc. It's kind of mind-bending to wrap your head around, and it definitely does help to spend some time reading the C code that Cython spits out to understand how the mapping works (it's both more and less magic than it looks -- Python stuff gets carefully expanded, C stuff goes through almost verbatim), but the end result works amazingly well. >> 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 >> using these particular APIs -- other than the Numpy stuff which probably >> does have a more elegant solution in the form of Cython arrays and >> memory views. > > yup -- that's what I noticed right away -- I"m note sure it there is > easier handling of file handles. 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. -n -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experiments in removing/replacing PyCXX
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/write_from a file that is already open, and in the middle of the file somewhere -- would that work? I just posted a question to the Cython list, and indeed, it looks like there is no easy answer to the file issue. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experiments in removing/replacing PyCXX
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
>> using these particular APIs -- other than the Numpy stuff which probably
>> does have a more elegant solution in the form of Cython arrays and
>> memory views.
OK -- so I poked at it, and this is my (very untested) version of
write_png (I left out the py3 stuff, though it does look like it may
be required for file handling...
Letting Cython unpack the numpy array is the real win. Maybe having it
this simple won't work for MPL, but this is what my code tends to look
like.
def write_png(cnp.ndarray[cnp.uint32, ndim=2, mode="c" ] buff not None,
file_obj,
double dpi=0.0):
cdef png_uint_32 width = buff.size[0]
cdef png_uint_32 height = buff.size[1]
if PyFile_CheckExact(file_obj):
cdef FILE *fp = fdopen(file_obj.fileno(), "w")
fp = PyFile_AsFile(file_obj)
write_png_c(buff[0,0], width, height, fp,
NULL, NULL, NULL, dpi)
return
else:
raise TypeError("write_png only works with real PyFileObject")
NOTE: that could be:
cnp.ndarray[cnp.uint8, ndim=3, mode="c" ]
I'm not sure how MPL stores image buffers.
or you could accept any object, then call:
np.view()
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
[email protected]
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experiments in removing/replacing PyCXX
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. > > yeah, that makes sense -- though what if you want to be able to > read_to/write_from a file that is already open, and in the middle of > the file somewhere -- would that work? > > I just posted a question to the Cython list, and indeed, it looks like > there is no easy answer to the file issue. 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 data, png_size_t count): fobj = png_get_io_ptr(s) pydata = PyString_FromStringAndSize(data, count) fobj.write(pydata) cdef void flush_pyfile(png_structp s): # Not sure if this is even needed fobj = png_get_io_ptr(s) fobj.flush() # in write_png: write_png_c(pix_buffer, width, height, NULL, file_obj, write_to_pyfile, flush_pyfile, dpi) But this is a separate issue :-) (and needs further fiddling to make exception handling work). Or if you're only going to work on real OS-level file objects anyway, you might as well just accept a filename as a string and fopen() it locally. Having Python do the fopen just makes your life harder for no reason. -n -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experiments in removing/replacing PyCXX
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 data, png_size_t count): > fobj = png_get_io_ptr(s) > pydata = PyString_FromStringAndSize(data, count) > fobj.write(pydata) Good point -- not at all Cython-specific, but do you need libpng (or whatever) to write to the file? can you just get a buffer with the encoded data and write it on the Python side? Particularly if the user wants to pass in an open file object. This might be a better API for folks that might want stream an image right through a web app, too. As a lot of Python APIs take either a file name or a file-like object, perhaps it would make sense to push that distinction down to the Cython level: -- if it's a filename, open it with raw C -- if it's a file-like object, have libpng write to a buffer (bytes object) , and pass that to the file-like object in Python anyway, not really a Cython issue, but that second object sure would be easy on Cython -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experiments in removing/replacing PyCXX
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 kind of tacked on and not a very good fit to > the problem. Not entirely relevant to the PyCXX discussion, but to avoid misleading others reading this discussion, I must strongly disagree with your assertion about Cython's usefulness for wrapping C libraries or small chunks of C. I think this has always been a primary function of Cython and Pyrex, as far back as I have been aware of them. I wrote the raw interface to our contouring code, and I have written cython interfaces to various chunks of C outside of mpl; and cython makes it much easier for a non-professional programmer such as myself. So I am not arguing that Cython should be the choice for removing PyCXX, but for non-wizards, it can work very well as glue. It is much more approachable than any alternative of which I am aware. For Fortran, of course, f2py plays this glue code generation role. Eric -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
