On Mon, Dec 3, 2012 at 8:24 PM, Chris Barker - NOAA Federal
<chris.bar...@noaa.gov> wrote:
> On Mon, Dec 3, 2012 at 11:59 AM, Michael Droettboom <md...@stsci.edu> 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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
