[Pyrex] defining module constants

Rob Shortt rob at tvcentric.com
Fri Apr 11 15:02:59 CEST 2008


Hi,

Robert Bradshaw wrote:
> On Apr 10, 2008, at 11:52 AM, Rob Shortt wrote:
>> Hello,
>>
>> I'm creating some python bindings to a C library.  I've defined
>> everything from the lib's header file in my pxd file and would like to
>> expose many of the defined enums in my pyrex module, not as members of a
>> class, but toplevel to my module.
>>
>> For example, in my pxd file I have stuff like:
>>
>> cdef extern from "directfb.h":
>>     ctypedef enum DFBResult:
>>         DFB_OK
>>         DFB_FAILURE
>>         DFB_INIT
>>         DFB_BUG
>>
>> and so on...
>>
>> What can I add to my pyx file so that my resulting module will have
>> these, like:
>>
>> import directfb
>> print directfb.DFB_OK
>>
>>
>> Please don't tell me I have to redefine or reassign them all in my pyx
>> file, but some equvalent to PyModule_AddIntConstant(m, "DFB_OK", DFB_OK)
>> would be ok.
> 
> I don't know of an automated way to do this, but perhaps we could make
> it so an enum could be declared "public" and all its members exported to
> the surrounding module (though one probably doesn't want those symbols
> in everything that uses your .pxd file.

I was looking for something like that but I guess it doesn't exist (yet). :)

I was thinking of this ever so long list of constants being in my
toplevel module but got thinking, in C they're all in the header file
and everything that includes it will have them in its namespace anyways.
 Also, anyone using my module will almost certainly need them available
unless they aren't doing much.

Another aproach would be to have some sort of static object in the
module that behaves like a sub module, named locals, constants, or
something:

from directfb.locals import *

Although that still fills the namespace with them (so I like the earlier
suggestion better).  Also, I wouldn't want to type directfb.locals.DFB_OK.

> One thing to note is that nothing prevents anyone from writing
> 
> directfb.DFB_OK = 389

How about public readonly?  Or have them set readonly internally.  While
messing around with this last night I discovered that readonly is only
for class members (not that we couldn't steal the keyword, etc).  Also I
think it would be fair to have enums readonly anyways (*disclaimer:  I'm
not much of a C programmer.)

Thanks,
-Rob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.copyleft.no/pipermail/pyrex/attachments/20080411/92065e9c/attachment.bin 


More information about the Pyrex mailing list