[Pythonmac-SIG] CFURL Pain
hengist.podd at virgin.net
Tue Mar 1 17:58:57 CET 2005
>>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
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?
>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
>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
>The standard library bits can't disappear, because that would break
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.
More information about the Pythonmac-SIG