[Pythonmac-SIG] CFURL Pain

[has]

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/