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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4