Bob wrote:
I wonder if it'd be easier just to hand-code wrappers
Actually, the easiest way is to just use PyObjC!
Maybe that's the way to go for CF stuff then: delegate the problem to PyObjC and get rid of the Carbon.CF extension completely (no sense in keeping broken modules if they're not worth fixing).
This still leaves Carbon APIs to deal with, however. For example, OSA.so is currently pretty broken, and I would happily go in and fix it myself but there's little point in doing so if all my changes have to be rewritten for bgen before they'll be accepted into the standard library. Plus Jack's very busy these days, so who knows when that would happen? And then there's stuff like Carbon.File, which could do with both bug fixes (the FSSpec problem) plus a new layer on top that abstracts away all the various and frequently crusty file types under one or two standard wrapper classes (might be possible to turn most of them into NSURLs, for example). How should these sorts of problems be tackled?
Additionally, since PyObjC wraps the functions with the signature they actually have, it's obvious (given Apple documentation or headers) how to use them. The way bgen wraps them attempts to objectify them, which tends to cause more problems than it solves -- at least for me.
I don't mind that so much as I object to the lack of documentation to tell you what's actually there and where to find it. These undocumented APIs are a serious PITA to grok. I end up generating my own erstaz docs by scraping an extension's type/method/function names and minimal docstrings into a text file and then cutting and pasting from Apple's original API docs or header file comments until I've got something that's at least minimally readable.
I do recall Jack saying something about maybe having a smaller core library and moving a lot of the non-essential stuff to an external package that could be managed independently
The Windows guys seem to get along just fine with this approach (re: win32all). There are a select few Win32-specific modules in the core, but most of the things you actually need are elsewhere.
So what would it take to get MacPython from its current state into that position?
has -- http://freespace.virgin.net/hamish.sanderson/ _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
