[Pythonmac-SIG] CFURL Pain

[has]

Bob wrote:

>>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 
>>known-to-be-broken-but-inviolable-now-as-it's-in-the-standard-library-neener-neener 
>>version?
>
>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
>
>Pick one.

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:
>>
>>     
>>app('TextEdit').documents[1].save(in_=FSSpec('/Path/To/NewFile.txt')
>
>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 
crap.


>>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?

has
-- 
http://freespace.virgin.net/hamish.sanderson/