[Pyrex] Newbie Missing a Fundamental Point?

[Kent Borg]

On Fri, Jul 21, 2006 at 09:24:36PM +0200, Stefan Behnel wrote:
> Pyrex can't parse .h files, but it still needs to know about their content to
> generate the right access code in C.
> 
> Just consider the .h files to be for the C compiler, while .pxd files are for
> Pyrex. Note that you only need to specify the parts of the .h files in your
> .pxd files that you actually use in your Pyrex code. The C compiler will have
> the full definitions available.

I think I get it.

After posting my question I considered whether I might have to write a
more conventional (non-Pyrex) Python extension.  In thinking about
what that would involve it occurred to me that the problem is the
same.  I was imagining that Pyrex magically (or with great work)
incorporated a C compiler.  Foolish me!

A point that I missed is that the "layout" of the Pyrex data structure
doesn't matter.  The C struct will be accessed by the C compiler, and
it will know where all the bits lie.

I think I also know the answer to another of my questions: How to
maintain two sets of .h files?  Answer: You don't.  There is only one
set of .h files.  In C if a .h file gets a change so that a .c file no
longer makes sense the compiler will complain.  Pyrex is a tool for
writing C code, and the compiler will complain in the corresponding
Pyrex case too.  In the case of the semantics of some C struct
changing, the .c file and the .pyx file are on the same footing, they
both need to be revisited in exactly the same way.

Another question: How does Pyrex execute the Python I might put in a
.pyx file?  Does it translate to C?  (Is Python really that clean that
the translation is practical?)


Thanks a bunch,


-kb, the Kent who won't be blaming Pyrex for design problems with his
legacy software.