[Pythonmac-SIG] CFURL Pain
hengist.podd at virgin.net
Tue Mar 1 21:08:02 CET 2005
>>1. What's the point of adding a new extension to the standard
>>library when that extension is not only untested but _already
>>known_ to be broken?
>They're automatically generated, these things happen.
Absolutely. I have no problem with mistakes being made. It's setting
them in stone that's the trouble.
>>2. What's the point of me going to the effort of writing a brand
>>new fully functioning OSA.so extension if it has to play perpetual
>>third fiddle to some
>Ok, there are three options:
>(1) Fix the current implementation
>(2) Write another, outside the standard library (unless you only
>care about Python 2.5+)
>(3) Live with a broken implementation
The only person in a position to do (1) is Jack, which is unfair on
both Jack and any third-party who might otherwise fix it themselves,
(2) is just ducking the issue and (3) is obviously a non-option.
(4) Remove the current implementation from the standard library.
In OSA.so's case this could be done completely painlessly as it's not
like anyone's actually using it. Older material may require more
delicate extraction and a proper repackaging to allow separate
installation, but it's still perfectly doable.
>>>Does that FSSpec bug really effect you? When do you need to pass
>>>FSSpecs to files that do not exist across processes?
>>Most commonly when saving new documents to file, as in:
>What you *actually* want is a Finder alias anyway.
Umm, no, I don't. I've been using file specs to refer to non-existent
files for years. It was the standard solution in OS9, and while
fileURL is supposed to supercede it in OS X it persists for legacy
reasons and because fileURL support still isn't quite what it should
be. And I've really no desire to start kludging up Python; I've
already endured enough kludges in AppleScript to last a lifetime and
the whole point of shifting to Python was to get away from all that
>>Kicking a lot of this stuff back out the standard library would be
>>a good start, because it's clearly not qualified to be there. Push
>>it into 'MacAll', and take it from there.
>Well obviously that's not an option,
Why? All it means users have to do two installs instead of one to get
set up which is no huge effort, and in practice the MacPython
installer could bundle and run a recent copy of the MacAll installer
for convenience. And once all this stuff is out the standard library
it's free to be working on without the onerous scheduling
restrictions and personnel bottleneck that comes from being locked up
in the standard library. Have I missed something?
More information about the Pythonmac-SIG