broken modules (was: Re: [Pythonmac-SIG] CFURL Pain)

[has]

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/