Bob wrote:
Maybe that's the way to go for CF stuff then: delegate the problem to PyObjC and get rid of the Carbon.CF extension completely (no sense in keeping broken modules if they're not worth fixing).
Unfortunately getting rid of an extension is a lot harder than it sounds. Better is to just stop using it, and possibly deprecate it.
Getting rid of junky crap takes time, but adding a warning and deprecating it at the nearest opportunity is a good start.
I don't think anyone is really using that module anyway.
All the more reason to deprecate it before they start to. :)
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?
*What* FSSpec problem with Carbon.File?
http://sourceforge.net/tracker/index.php?func=detail&aid=706592&group_id=5470&atid=105470
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).
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?
The standard library bits can't disappear, because that would break compatibility.
Add warnings to these modules and deprecate them now. Strip all their documentation out of the main Python docs and leave it in a separate 'Deprecated Docs' package preserved for legacy use only. Get all the crap well away from ordinary decent users as quickly as possible.
Depending on how much a deprecated item is used it could be removed completely in the following major release, moved to 'MacAll' at some point or left in the core library indefinitely. There's quite a bit of obsolete stuff in the standard library that's been broken or non-functional since OS9. With 2.4 finally throwing off OS9 commitments it seems the ideal time to get brutal with the useless baggage and strike a red marker through everything that doesn't measure up. You'll inevitably be leaving folks behind anyway, so make the most of the opportunity.
Even if modules don't go completely, scrubbing the code to get rid of the cruft leaving only warnings and non-functional stubs might be a good idea. It's not worth twisting oneself into religious knots to preserve some perceived 100% backwards-compatibility over code that probably hasn't worked or been used in years. Future health, vitality and growth are much more important, and worth an occasional minor break with the ancient past.
Of course, this is assuming that more robust alternatives to the standard library's exists.
Even if there isn't, leaving broken stuff in the core library isn't doing any favours. If it's recoverable, why not punt it into MacAll where its failings can be addressed more easily? If it's terminal, put it on the road to disposal. I don't have a problem throwing out stuff that's definitely had it: you may see this as leaving a void, but I see it as creating a fresh new opportunity.
Cheers,
has -- http://freespace.virgin.net/hamish.sanderson/ _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
