[Pythonmac-SIG] CFURL Pain

[has]

Bob wrote:

>>>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?
>
>Unlikely, but what does it matter?

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?

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?

Aside from the self-evident foolishness of loading the standard 
library full of worthless crap, it's also rather insulting to folk 
who spend the time and effort to write and thoroughly field-test code 
before even thinking of submitting it for possible future inclusion, 
only to see rubbish getting fast-tracked right past them. Come to 
think of it, it's somewhat insulting to MacPython users in general: 
"Sure the quality sucks ass, but just feel the quantity!" If bulk's 
all you want, just pack line noise into modules and release that; 
it'll work just as well and be even easier to produce.

I may not know much about programming, but I know what a bullethole 
in the foot looks like. If nobody cares enough about using these new 
wrappers to test and debug them thoroughly before inclusion, they 
should not go in, period. Simple as that. All it does is create a 
mess that then can't be cleaned up properly, because throwing out a 
busted-ass module that _nobody can actually use_ will somehow - oh 
noes!!!!!!1!1! - 'break compatibility'.


>>>*What* FSSpec problem with Carbon.File?
>>
>>http://sourceforge.net/tracker/index.php?func=detail&aid=706592&group_id=5470&atid=105470
>
>Ah, right.  I ran into that problem once with QuickTime, but it 
>turned out that there was another way.

Do tell!


>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')


>>>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?
>
>I don't see what its origins have to do with anything..  You 
>obviously can't give it the same __name__ as something in the 
>standard library.

That would be my point. Python users don't want, need or deserve to 
thrash through a dozen different first- and third-party 
implementations of the same module to find one that works. There 
should be one way to do it, and that solution should NOT be in the 
standard library unless it can swear, hand on heart, that it's the 
Right One. 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.

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