Bob wrote:
Absolutely. I have no problem with mistakes being made. It's setting them in stone that's the trouble.
Not stone, just molasses.
Near enough as makes no practical difference. It's a situation that should not occur in the first place. These molasses are entirely man-made.
If you learn bgen and submit proper patches
Without proper documentation and tutorials? Sorry, but masochistic self-flagellation is not my thing. This is somebody else's house of cards to sort out before everyone else can seriously be expected to play in it.
Besides, what's the point in me going to the trouble of properly patching something if the fix won't percolate into the main distribution for another year when I need it now?
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.
No, I'm using OSA.so as an illustrative example because I'm already familiar with it. The point is that potentially broken modules should not be going into standard library. And until they've been tested, all modules should be considered potentially broken. OSA.so is a prime example: I _know_ it hasn't been tested, because it took me five minutes to discover the first deal-killer bug. Other modules may be just as untested, but I can't speak for them as I've not tried them myself.
In the case of OSA.so and any other new MacPython 2.4 additions that haven't been tested, until Jack posts a final MacPython 2.4 distribution then it ought to be safe to revoke their inclusion.
Removing the extension may or may not be a good idea. If /some/ of it works, it might be worth keeping.
In OSA.so's case the breakage is pretty fundamental, e.g. not being able to compile scripts from source is pretty much a deal-breaker by itself, never mind the other bugs and huge chunk of missing API. I hear no great clamour from the gallery to use this module, broken or otherwise, so just punt the bastard out. It's virtually worthless as it is, and sticking it in will only make it harder to clean up the mess later on.
Other modules I can't speak for, other than to say that if nobody's tested them yet then it would be better to keep them out than until they are. If folk really care about them, they'll whip together and run some tests quickly enough. And if they don't care about them, it means those modules aren't worth including in the standard library in the first place. (Seriously, what are the justifications for putting stuff nobody needs or wants into the standard library?)
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!
Why so long? Merely refactoring the distribution doesn't break backwards compatibility so I don't see why the reorganisation couldn't be done during 2.4's tenure?
My point is that it's perfectly fine to IGNORE THE STANDARD LIBRARY.
It's fine for users to avoid the standard library. But that doesn't excuse filling it up with crap and then saying we shouldn't be concerned by this behaviour because users can always go elsewhere if they don't like it. Different issue. If you can't see any problems in having two parallel libraries: one an officially sanctioned and bundled broken-ass POS and the other a giant third-party band-aid, then you really need to start looking harder. The damage it could cause MacPython's public image and credibility alone should be of significant concern. It's like letting your house get covered in three feet of rotting unwashed dishes and cat poop and then wondering why nobody wants to come round and visit any more. It does a disservice to Python's reputation, its developers and its end-users, and it's the sort of behaviour that'll eventually turn folk off Python and onto something else.
My point? Doing a job badly is the _worst_ thing possible. If you can't or won't do it properly, you shouldn't to do it at all.
has -- http://freespace.virgin.net/hamish.sanderson/ _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
