[Pythonmac-SIG] CFURL Pain
Bob Ippolito
bob at redivi.com
Tue Mar 1 18:11:44 CET 2005
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
More information about the Pythonmac-SIG
mailing list