[Pythonmac-SIG] ANN: Preview of SystemConfiguration wrapper

[Bob Ippolito]

On Sunday, Oct 19, 2003, at 12:52 America/New_York, Ronald Oussoren 
wrote:

>
> On 19 okt 2003, at 15:25, Bob Ippolito wrote:
>
>>
>> On Sunday, Oct 19, 2003, at 08:57 America/New_York, Ronald Oussoren 
>> wrote:
>>
>>>
>>> On 19 okt 2003, at 9:51, Bob Ippolito wrote:
>>>
>>>> http://undefined.org/python/SystemConfiguration-0.1.tar.gz
>>>>
>>>> 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've done it before, it's not super hard.. if you look at the 
PyQTSequence application on http://undefined.org/python/ I have the 
Quicktime bgen wrapper building outside the Python source tree.

>
>> 	- 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 API.

Sure.  That can be solved though even if you rename the methods by 
keeping metadata as to what is wrapped.  I've been thinking about doing 
that but I wanted to write the wrapper and not a code generator at this 
point.

>> 	- 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.

Maybe, but the ObjC stuff is pretty good at wrapping CoreFoundation 
APIs.

>> 	- 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 
> instances).

I wanted to raise the exception with as much information as possible.. 
I wrote a script to take the enumerator out of the header file and 
extract the documentation as well so it can raise that (see the huge 
+load).  I didn't want to mess with anything Python specific so it can 
be used from pure ObjC.  I think there's a demand for a nicer wrapper 
than MoreSCF, because I don't see a lot of people using 
SystemConfiguration yet.

-bob