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