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

[Bob Ippolito]

On Mar 2, 2005, at 9:51, has wrote:

> Bob wrote:
>
>> 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.

Yet you screw around with the Carbon modules, which also have no 
documentation or tutorials?

> 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?

If the fix didn't consist of adding new features, and you submitted it 
today, it could be in 2.4.1 in less than two weeks.

>> 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.

The extension(s) are part of Python 2.4, and follow the same policy as 
anything else in there.  The lack of a binary release doesn't really 
mean anything.

>> 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?)

It's already there, so it's not going anywhere in 2.4.  The 
justification is that people *did* ask for an OSA wrapper -- I believe 
you were one of the larger proponents.  It's partially your fault for 
not testing it *before* final release.

>>>>> 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?

As I stated before, "MacAll" can't use the Carbon namespace, so this 
trivial reorganization is not possible.

>> 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.

Very few people care that undocumented modules don't work correctly.  
You have to look pretty hard to even notice their existence in the 
first place.  I've never heard of a broken undocumented standard 
library module becoming a deal-breaker for someone new to Python.

-bob