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/ _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
