[Pythonmac-SIG] ANN: Preview of SystemConfiguration wrapper
oussoren at cistron.nl
Sun Oct 19 12:52:34 EDT 2003
On 19 okt 2003, at 15:25, Bob Ippolito wrote:
> On Sunday, Oct 19, 2003, at 08:57 America/New_York, Ronald Oussoren
>> On 19 okt 2003, at 9:51, Bob Ippolito wrote:
>>> This is a source distribution, it requires PyObjC and Developer
>>> Tools. The wrapper itself is (entirely) an ObjC framework, but it
>>> includes everything necessary for Python wrapping. I haven't done
>>> any documentation, real tests, especially testing of the runloop
>>> integration.. but here it is if someone wants to play with it. The
>>> ObjC is a little sloppy (three classes in one file), and the
>>> setup.py is a lot sloppy (thanks to distutils being not easily
>>> extensible), but it works.. or at least it should.
>> I haven't looked at your code yet, but wouldn't it be better to
>> generate the wrapper using bgen? That would make the wrapper easier
>> to maintain and easier to integrate into MacPython/the python core.
>> The CodeGenerator scripts in PyObjC could also be coaxed into
>> generating a functioning wrapper That is, without significant changes
>> to the scripts. The prototypes are different enough to require
>> changes to the "parser".
> I decided against bgen for a couple reasons:
> - bgen is hard to use
Yup, that's why PyObjC contains Scripts/CodeGenerator :-), writing
those scripts was easier than getting bgen to work correctly.
As I never managed to get a working bgen setup I cannot say if bgen is
really hard to use or if it's just the lack of documentation that makes
it so hard to use.
> - I'm not yet convinced that the code generators save that much time
> in the long run
An important advantage of code generators is that you end up with a
consistantly translated API. This may not be the perfect API, but makes
it so much easier to use existing documentation and examples (all
targetting the C API) when writing Python scripts that use the wrapped
> - I wrote it by mostly by hand so I know that each and every method
> has been "audited" by someone to at least look like it should work ;)
> - Using a bgen-generated Python module doesn't feel much better than
> coding in C. These are named so that the module feels like they're
> using PyObjC.
See me previous point, a more python-like interface is not necessarily
an advantage. That won't keep me from using your wrappers though, the
look pretty usefull as they are.
> - SystemConfiguration is one of those
> should've-already-been-wrapped-in-ObjC-by-Apple frameworks that uses a
> lot of CoreFoundation types, so the bridge code is already in PyObjC
> for the most part (lots of CFDictionaryRef, CFArray, CFString, etc.)
I've been thinking about this. Should there be a 'PyCF' "project" for
building good wrappers for CoreFoundation(-based) APIs? This could be
done by changing the bgen scripts in MacPython, adapting the
CodeGenerator scripts from PyObjC or writing something from scratch.
> - It might be useful from ObjC someday. Surely by someone in the
> ObjC community that isn't using any or a lot of Python yet.
> - The SystemConfiguration framework has awkward rules about when you
> need to check for errors, so I'd have to write a lot of helpers by
> hand anyway. Since bgen helpers are in C, not ObjC, it would be much
> more of a pain in the ass to write them (i.e. more like 20 lines of
> code per hand-wrapped function instead of an average of maybe 4 here).
Your ObjC wrappers seem to use a seperate function for raising the
exception. A simular solution could be used in bgen-based wrappers
(which could use ObjC to access the contents of CFArray/NSArray
More information about the Pythonmac-SIG