[Pythonmac-SIG] CFURL Pain

[Bob Ippolito]

On Feb 28, 2005, at 6:16 PM, has wrote:

> Bob wrote:
>
>>>> Well I can verify that there definitely are serious problems with 
>>>> CFURL after screwing around with it a bit.
>>>
>>> Figures. Yuck. Must be bgen's revenge for all the nasty things we 
>>> ever said about it.
>>
>> All the nasty things I ever said about it are because of things like 
>> this :)
>
> But it's so quick! As long as you're Jack and know how to use it. If 
> you're not Jack, I guess you're screwed. On second thoughts, given 
> Jack's existing To-Do list is probably the size of K2 he's probably 
> screwed too. :p
>
> I wonder if it'd be easier just to hand-code wrappers using Pyrex, 
> perhaps with a very basic macro system that automates only the 
> simplest of tasks. A lower level automation that works well might 
> ultimately be more productive than total automation that tends towards 
> flakiness. While a single person wouldn't be able to wrap nearly as 
> many APIs, the wrappers that did get done would probably be more 
> reliable due to the extra attention; maybe a bit nicer to use too. 
> Plus it'd make it easier for more folk to write these wrappers, taking 
> some pressure off Jack.

Actually, the easiest way is to just use PyObjC!  It is extremely well 
suited to tackle wrapping CoreFoundation functions and types since they 
conform to the NSObject protocol.  Many of them have toll-free bridges 
into their Objective-C types, which have a richer interface, and PyObjC 
understands this too.

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 
wouldn't think to look for a method of CFStringRef to create a CFURL!

>>>> Too bad :)  If you're writing Mac OS X specific code you **really** 
>>>> should have PyObjC anyway.
>>>
>>> Oh, I have. It's all the casual users who don't that present the 
>>> problem. If PyObjC is going to be so essential to all aspects of 
>>> MacPython usage then it's really time for it to join the standard 
>>> library.
>>
>> So let's offer a package that includes appscript, PyObjC, and py2app 
>> in one installer.
>
> 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; kind of a 'second tier'. 
> Perhaps that would be the way to do it: more flexibility for 
> individual package developers since they're not tied to the official 
> Python upgrade cycle while still providing a quick and simple one-stop 
> installation for users. Even modules that are destined for the core 
> library would benefit from spending some time at this halfway house 
> first while all the kinks are worked out (e.g. OSA.so). Might be worth 
> exploring to see what sort of infrastructure it would require to run.

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.

-bob