On Mar 1, 2005, at 9:55 AM, has wrote:
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).
Unfortunately getting rid of an extension is a lot harder than it sounds. Better is to just stop using it, and possibly deprecate it. I don't think anyone is really using that module anyway.
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?
It's unlikely that anyone is going to ever bother doing a better job wrapping Carbon than is already done, because it's a hell of a lot of work and Carbon isn't really the best way to do most things anyway.
Instead of fixing OSA, you can write an alternative that isn't bgen based.
*What* FSSpec problem with Carbon.File? Although there is generally not a very good reason to use FSSpec or FSRef, unless you're working with resource forks or Aliases, I haven't had problems with Carbon.File at all. This is probably the most robust module in the bgen Carbon wrappers, as it's the one that actually gets used.
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.
Well the problem I have is that even if you know the C API then you will stumble with the Pythonized version of it (with bgen generated stuff).
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?
Just tell people to stop using standard library stuff and use the more robust alternatives. The standard library bits can't disappear, because that would break compatibility. Of course, this is assuming that more robust alternatives to the standard library's exists.
-bob
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
