On dimanche 06 juillet 2008, Guy K. Kloss wrote: > That depends on the way you implement it. You basically define the > binding (parameter type lists, rules on how to handle pointers, etc.) in > Python structures. The library itself is loaded dynamically, and through > the binding description Python knows how to map from Python types to the > C/native types. You can also define code that converts from e. g. > arbitrary array types to the native types, performs checks, etc. > > I would envision the procedure like this: > 1. create (preferably auto-generate) a basic wrapper to the library: > --> _lcms.py module or something like that > 2. create an lcms.py module that imports all of _lcms and > adds/overrides stuff to make the calling API more pythonic > 3. create an OO API to handle lcms nicely for convenience in > applications
Sounds good :o) > The idea behind it is to work in a way like e. g. popen. There are the > popen functions, and then there's the Popen class that gives more > elegant access to the functionality. The _lcms module, as auto-generated > would of course NOT be edited directly, so that it can easily be updated > through the generator on any code changes to the lcms code base > (lcms.h). But that shouldn't provide any problems, as Python is so nice > and dynamic in its way that it all can easily be overridden, modified, > appended, decorated, ... popen-like module should be great! BTW, you still need swig/boost to automatically wrap and generate _lcms.py, don't you? -- Frédéric http://www.gbiloba.org ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Lcms-user mailing list Lcms-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lcms-user