Re: defining module constants
Rob Shortt <[email protected]>
| Newsgroups | gmane.comp.python.pyrex |
|---|---|
| Message-ID | <[email protected]> |
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 _______________________________________________ Pyrex mailing list [email protected] http://lists.copyleft.no/mailman/listinfo/pyrex
signature.asc
(application/pgp-signature, 252 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH/2GIJ+LOBHZ1wCsRAr+oAKCEZC8dHs3tgUrMKblVXNnXDUicUwCfQsDS PZjG00Rm4dFN43TEnxMYuSU= =ZrFk -----END PGP SIGNATURE-----