[Pythonmac-SIG] CFURL Pain

[Bob Ippolito]

On Mar 1, 2005, at 11:58 AM, has wrote:

> Bob wrote:
>
>>> This still leaves Carbon APIs to deal with, however.
>>
>> 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.
>
> True and semi-true (there's still functionality in Carbon that's not  
> in Cocoa). However, it's not a case of wrapping all of Carbon simply  
> as a point of principle, but rather individuals wrapping the bits they  
> need themselves as needed and that code ultimately making it into the  
> official distribution.
>
>> Instead of fixing OSA, you can write an alternative that isn't bgen  
>> based.
>
> If I do that, will the current OSA.so be thrown out (preferably right  
> now) and replaced with my version once it's done?

Unlikely, but what does it matter?  We're talking about making a  
package separate from the standard library.  Even if it did happen  
"right now", that would mean Python 2.5, which really means "probably  
next year".

>> *What* FSSpec problem with Carbon.File?
>
> http://sourceforge.net/tracker/index.php? 
> func=detail&aid=706592&group_id=5470&atid=105470

Ah, right.  I ran into that problem once with QuickTime, but it turned  
out that there was another way.

>> Although there is generally not a very good reason to use FSSpec or  
>> FSRef,
>
> Legacy mostly, e.g. when dealing with Carbon APIs that use them. In my  
> case, because they're still heavily used by scriptable apps and  
> Apple's built-in coercions aren't sufficiently up to snuff to let me  
> ignore them outright (which is damned annoying, especially when  
> they're the ones telling us we should now be ignoring these and using  
> their shiny new types instead).

Does that FSSpec bug really effect you?  When do you need to pass  
FSSpecs to files that do not exist across processes?

>>> 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.
>
> What when there's overlap, e.g. the 'robust alternative' is a modified  
> version of the original - say, a partially rewritten OSA.so extension?

I don't see what its origins have to do with anything..  You obviously  
can't give it the same __name__ as something in the standard library.

-bob