[Pythonmac-SIG] CFURL Pain

[has]

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/