[Pythonmac-SIG] CFURL Pain

[Bob Ippolito]

On Mar 1, 2005, at 3:08 PM, has wrote:

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

Not stone, just molasses.  If you learn bgen and submit proper patches,  
you can fix existing modules in the 2.4 maintenance branch and add/or  
features to the 2.5 branch.

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

You can learn bgen and fix it the correct way, and submit a patch.   
Jack doesn't need to commit the patch.  I did this once or twice, it's  
possible for someone other than Jack to do it.

You're confusing issues here.  The problem is that you need OSA  
functionality.  Removing something from the standard library does  
nothing to solve that problem.

Removing the extension may or may not be a good idea.  If /some/ of it  
works, it might be worth keeping.

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

FSSpec is legacy.  It should not ever be used in any code except to  
reference nonexistent files or to deal with legacy APIs.  You shouldn't  
use them if the API will take an FSRef or an Alias.  In this case, the  
API *asks* for an Alias.  So, yeah, you do actually want an Alias.

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

It can't happen until Python 2.6 at the earliest.  I don't think it's  
very likely to go away anyway.  Good luck!

My point is that it's perfectly fine to IGNORE THE STANDARD LIBRARY.   
Whether or not the Carbon package exists in the standard library has no  
effect whatsoever on a "MacAll" package!  The only harm it's doing is  
taking up the name 'Carbon' in the sys.modules namespace.  For  
compatibility reasons, the MacAll package can't use the name Carbon  
anyway.

-bob