[Pythonmac-SIG] Finding what a broken alias refers to.

Bob Ippolito bob at redivi.com
Fri Jun 24 15:35:33 CEST 2005


On Jun 24, 2005, at 9:27 AM, Dethe Elza wrote:

> Ronald Oussoren wrote:
>
>
>> Someone with copious free time should build new Carbon wrappers, we
>> can than ask if the existing wrappers can be dropped in a future
>> version of Python. Sadly enough that probably is with python 2.6 at
>> the earliest, which is a long way away.
>>
>>
>
> Would there be any benefit to documenting bgen?  It seems like the  
> functionality it provides is useful, so that might be the first  
> step to building a worthy replacement. Or do you feel that the bgen  
> approach is fundamentally flawed?  And if so, what should be done  
> to replace it?  You're not suggesting manually wrapping Carbon, are  
> you?

The bgen approach is pretty flawed, it's an incomplete parser of the  
C header grammar that Apple *used to* use.  As soon as Apple stops  
maintaining Universal Headers, bgen will be more or less dead in the  
water.

We have some slightly more technically sound parsing in PyObjC's  
sandbox, but it's designed for the Objective-C grammar, and doesn't  
cover all of C.

If it was really that useful, it'd have been used for *something*  
other than the Carbon stuff.  It's ancient.

Nobody is suggesting that we manually wrap Carbon.

> Bob Ippolito wrote:
>
>
>> The problem with Carbon wrappers is that they have such diminishing
>> returns.  The longer you wait, the less reason there is to use Carbon
>> in the first place.
>>
>> If we just sit on our hands for another few years, all of the
>> functionality in Carbon will be available elsewhere anyway :)
>>
>>
>
> So in that scenario we don't need bgen at all, right?  But there is  
> still a significant chunck of functionality that is not exposed to  
> Cocoa.  Unfortunately, I don't know what the borders look like  
> until I stumble across them (and the new Quicktime framework  
> definitely shifted the borders pretty significantly).

Most of the significant chunks of (new) functionality lives in  
CoreFoundation-like libraries, which are close enough to Objective-C  
that PyObjC will wrap them eventually.  PyObjC will not try and make  
OO wrappers for any of the functionality, though, so there will be a  
1:1 correspondence with the Apple documentation and what you should  
be doing from Python.

>> I have no intention whatsoever to work on new Carbon wrappers because
>> all functionality I need is already available elsewhere. However, we
>> do need a plan to get rid of the current wrappers (especially the
>> Carbon.CF ones) to make room for better ones. I do want to add
>> wrappers for CoreFoundation (and frameworks based on CoreFoundation)
>> to PyObjC and would like to drop for Carbon.CF when that's done.
>>
>> There may be other frameworks that are useful (OSA stuff, QuickTime)
>> and could use wrappers with betters tests and documentation.
>
> Is there a hitlist of frameworks that would be good to support, but  
> are not supported yet? What are some of the best targets for  
> someone who wants to jump in and help out?

The most useful work would be hacking on the parser/generator in  
PyObjC's sandbox.

-bob



More information about the Pythonmac-SIG mailing list