Dan Stromberg wrote:
SIP's approach of using something close to, but not identical to, the .h's
sounds like it might be pretty productive - especially if the derivative
of the .h's could be automatically derived using a python script, with
minor
tweaks to the inputs on .h upgrades. But sip
On Tue, Aug 30, 2011 at 10:05 AM, Guido van Rossum gu...@python.org wrote:
On Tue, Aug 30, 2011 at 9:49 AM, Martin v. Löwis mar...@v.loewis.de
wrote:
The problem lies with the PyPy backend -- there it generates ctypes
code, which means that the signature you declare to Cython/Pyrex must
You might be reading more into that statement than I meant.
You have to supply Pyrex/Cython versions of the C declarations,
either hand-written or generated by a tool. But you write them
based on the advertised C API -- you don't have to manually
expand macros, work out the low-level layout
Martin v. Löwis, 30.08.2011 10:46:
You might be reading more into that statement than I meant.
You have to supply Pyrex/Cython versions of the C declarations,
either hand-written or generated by a tool. But you write them
based on the advertised C API -- you don't have to manually
expand macros,
Meador Inge meadori at gmail.com writes:
1. http://bugs.python.org/issue9041
I raised a question about this patch (in the issue tracker).
2. http://bugs.python.org/issue9651
3. http://bugs.python.org/issue11241
I presume, since Amaury has commit rights, that he could commit these.
I also have some patches sitting on the tracker for some time:
http://bugs.python.org/issue12764
http://bugs.python.org/issue11835
http://bugs.python.org/issue12528 which also fixes
http://bugs.python.org/issue6069 and http://bugs.python.org/issue11920
http://bugs.python.org/issue6068 which also
I can understand how that works when building a CPython extension.
But what about creating Jython/IronPython modules with Cython?
At what point get the header files considered there?
I had written a bit about this here:
http://thread.gmane.org/gmane.comp.python.devel/126340/focus=126419
On Tue, Aug 30, 2011 at 9:49 AM, Martin v. Löwis mar...@v.loewis.de wrote:
I can understand how that works when building a CPython extension.
But what about creating Jython/IronPython modules with Cython?
At what point get the header files considered there?
I had written a bit about this
On 8/30/2011 1:05 PM, Guido van Rossum wrote:
I see. So there is potential for error there.
To elaborate, with CPython it looks pretty solid, at least for
functions and constants (does it do structs?). You must manually
declare the name and signature of a function, and Pyrex/Cython emits C
Guido van Rossum, 30.08.2011 19:05:
On Tue, Aug 30, 2011 at 9:49 AM, Martin v. Löwis wrote:
I can understand how that works when building a CPython extension.
But what about creating Jython/IronPython modules with Cython?
At what point get the header files considered there?
I had written a
Guido van Rossum wrote:
On Sun, Aug 28, 2011 at 11:23 AM, Stefan Behnel stefan...@behnel.de wrote:
Hi,
sorry for hooking in here with my usual Cython bias and promotion. When the
question comes up what a good FFI for Python should look like, it's an
obvious reaction from my part to throw
2011/8/29 Glyph Lefkowitz gl...@twistedmatrix.com:
On Aug 28, 2011, at 7:27 PM, Guido van Rossum wrote:
In general, an existing library cannot be called
without access to its .h files -- there are probably struct and
constant definitions, platform-specific #ifdefs and #defines, and
other
Guido van Rossum wrote:
(Just like Python's own .h files --
e.g. the extensive renaming of the Unicode APIs depending on
narrow/wide build) How does Cython deal with these?
Pyrex/Cython deal with it by generating C code that includes
the relevant headers, so the C compiler expands all the
On Sat, Aug 27, 2011 at 11:58 PM, Terry Reedy tjre...@udel.edu wrote:
Dan, I once had the more or less the same opinion/question as you with
regard to ctypes, but I now see at least 3 problems.
1) It seems hard to write it correctly. There are currently 47 open ctypes
issues, with 9 being
On Mon, Aug 29, 2011 at 2:17 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Guido van Rossum wrote:
(Just like Python's own .h files --
e.g. the extensive renaming of the Unicode APIs depending on
narrow/wide build) How does Cython deal with these?
Pyrex/Cython deal with it by generating
Guido van Rossum wrote:
On Mon, Aug 29, 2011 at 2:17 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
All you
need to do when writing the .pyx file is follow the same
API that you would if you were writing C code to use the
library.
Interesting. Then how does Pyrex/Cython typecheck your
On Sun, Aug 28, 2011 at 6:58 AM, Terry Reedy tjre...@udel.edu wrote:
2) It is not trivial to use it correctly. I think it needs a SWIG-like
companion script that can write at least first-pass ctypes code from the .h
header files. Or maybe it could/should use header info at runtime (with the
.h
Hi,
sorry for hooking in here with my usual Cython bias and promotion. When the
question comes up what a good FFI for Python should look like, it's an
obvious reaction from my part to throw Cython into the game.
Terry Reedy, 28.08.2011 06:58:
Dan, I once had the more or less the same
On Sun, Aug 28, 2011 at 11:23 AM, Stefan Behnel stefan...@behnel.de wrote:
Hi,
sorry for hooking in here with my usual Cython bias and promotion. When the
question comes up what a good FFI for Python should look like, it's an
obvious reaction from my part to throw Cython into the game.
On Mon, Aug 29, 2011 at 12:27 PM, Guido van Rossum gu...@python.org wrote:
I wonder if for
this particular purpose SWIG isn't the better match. (If SWIG weren't
universally hated, even by its original author. :-)
SWIG is nice when you control the C/C++ side of the API as well and
can tweak it
On Aug 28, 2011, at 7:27 PM, Guido van Rossum wrote:
In general, an existing library cannot be called
without access to its .h files -- there are probably struct and
constant definitions, platform-specific #ifdefs and #defines, and
other things in there that affect the linker-level calling
Dan, I once had the more or less the same opinion/question as you with
regard to ctypes, but I now see at least 3 problems.
1) It seems hard to write it correctly. There are currently 47 open
ctypes issues, with 9 being feature requests, leaving 38
behavior-related issues. Tom Heller has not
22 matches
Mail list logo
