broken modules (was: Re: [Pythonmac-SIG] CFURL Pain)
has
hengist.podd at virgin.net
Wed Mar 2 15:51:14 CET 2005
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/
More information about the Pythonmac-SIG
mailing list