Re: [Pyobjc-dev] Bridging enumerated types

[Bill B. <bb...@co...>]

Have a look at they way python builds the socket.py library.  In particular, it
has a look at the system header files and defines constants within the socket.py
module based on values found in system specific headers.

It is more designed for handling the changes in values across different
platforms, but may provide some useful seeds for doing what you want!

Sounds like a very cool project!

b.bum

On Sun, 15 Apr 2001, Leigh Smith wrote:

> The Python-ObjC works really well for interfacing the MusicKit (non-GUI) to
> Python, thanks to the developers!
> 
> One issue we face is that the MusicKit uses a very large collection (200
> odd) of enumerated types for musical note parameters (pitch, duration,
> synthesis parameters etc). It would be really nice to define these within
> Python, but to avoid synchronizing between two code bases, it would be nicer
> to have them automatically derived from the C source.
> 
> Two approaches come to mind, either I create a C function that includes the
> params.h file (containing the enums) and then exports them via the usual
> Python C bridge or I write a python script to read a header file, extract
> all the enums (including integer assignments) and create the variables then.
> 
> The issues I can see are the former could require a lot of repetitive code
> (possibly automatically created using sed/Python/perl) and would require
> that binary to be complied and placed into the standard Python library area.
> Each program would then need a "import MusicKit" statement, which could (I
> assume) do the NSBundle.load('MusicKit.framework') statement.
> 
> The latter parsing approach would need to create all the variables at run
> time (obviously possible, but I currently lack that knowledge of Python) and
> would follow the NSBundle.load('MusicKit.framework') statement with
> something like enumParse('MusicKit.framework/Headers/params.h').
> 
> Perhaps there is already some similar solution since this is not ObjC
> specific, any bridge to a large C code base using many enums would have the
> same issue. Of course I'd look to contribute the solution to either pyobjc
> or the standard Python archive, depending on where it is best located.
> 
> Any suggestions?
> 
> 
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> http://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>