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
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
