[Pythonmac-SIG] CFURL Pain

[Bob Ippolito]

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