Re: [ctypes-users] Simple way to call a function with struct flockargument [SEC=PERSONAL]

[Andrew M. <And...@ac...>]

> > Your problem belongs to "writing cross platform" code domain. There
> > are a lot of documents on the Internet that cover this topic.
> 
> Hmm... I don't think that my problem really falls under 
> what's commonly
> discussed in that context.
> 
> Suppose there is a header <myhdr.h> that differs from platform to
> platform:
> 
> typedef mytype_t int;
> void do_something(mytype_t a);
> 
> Then the following program will work on any system, no matter how
> mytype_t is defined on that system (it could be long, double, short
> etc.):
> 
> #include <myhdr.h>
> void bla()
> {
>         mytype_t a = 42;
>         do_something(a)
> }

After compilation, you will have a platform specific executable.  Before

compilation you only have source code.  The compiler is handling the 
cross-platform issues for you; Python code has to handle the cross 
platform issues at runtime.

So I would say that the "writing cross platform code" characterisation 
is correct.

> The problem only arises when I want to call do_something() 
> from Python,
> and it is caused by the way that PyArg_ParseTuple has been 
> implemented.
> What I need to do is write something like this:
> 
> #include <myhdr.h>
> static PyObject * do_sth_from_python(PyObject *self, PyObject *args)
> {
>         mytype_t a;
> 
>         #if mytype_t has type int
>             PyArg_ParseTuple(args, "i", &a);
>         #else if mytype_t has type long
>             PyArg_ParseTuple(args, "l", &a);
>         #else if mytype_t has type double
>             PyArg_ParseTuple(args, "d", &a);
>         #endif
>         
>         do_something(a);
> }
> 
> In other words, PyArg_ParseTuple only determines the type of its
> argument at runtime from the format string, but I only know the
> type of mytype_t at compile time without being able to save it in a
> string for use during runtime.
> 
> > You can determine at compile time on what platform you are and what
> > preprocessor flags are "on" and based on this to write the code.
> 
> I don't see any way to write the above #if lines as real preprocessor
> directives, nor do I see a way to write them in C and have 
> them executed
> at runtime. Is it possible to do so?

Weave (http://www.scipy.org/Weave) can achieve the effect you 
ask for, at the cost of using a real compiler.

Pyrex and Cython are packages which can be used to build C extensions 
more easily than writing the C interface code by hand (or trying to 
write Python+ctypes code for complex cases), but you still need 
to build extension modules for each platform supported.

Your expectations of ctypes are beyond its capability.  However 
there is at least one tool available to do some of the grunt work of 
analysing C header files for you: ctypeslib - see the "Related projects"

section of http://starship.python.net/crew/theller/ctypes/.
AFAICT thoug, ctypeslib will only give platform specific output as it is

post-processing C compiler output.

The distutils package also provides some capabilities which you might 
be able to leverage to identify the build environment of the running 
Python interpreter, such as distutils.sysconfig.  If large file offsets 
are optional on a platform, and Python was built with that option, then 
this might be a way to identify that (though I've never tried that 
level of introspection).

You will need to assemble suitable definitions for each platform
specific 
construct as it expands on each platform, and select the appropriate 
ones at runtime based on inspecting the runtime environment.

This is a standard Python approach to cross platform support - Python 
after all does not try and abstract away all platform differences.

Note that for basic types, ctypes will use objects sized appropriately 
for the platform: e.g. a ctypes c_int is sized as a C int variable would

be by the C compiler for that platform.

-------------------------> "These thoughts are mine alone!" <---------
Andrew MacIntyre           National Licensing and Allocations Branch
tel:   +61 2 6219 5356     Inputs to Industry Division
fax:   +61 2 6253 3277     Australian Communications & Media Authority
email: and...@ac...            http://www.acma.gov.au/ 

If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments may be private, confidential and legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose, use, forward, or distribute this email and/or its contents.
 
Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual cases. Opinions contained in this email or any of its attachments do not necessarily reflect the opinions of ACMA.