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

[has]

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?

No more than I can help. And there is documentation if you're willing 
to work through docstrings and Apple docs to extract the relevant 
info. It's not much fun, but it's doable.


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

With specific regard to OSA.so, of course it would consist of adding 
new features: half the damn OSA API is missing from the stupid thing.


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

Whatever; if it's too late to change then write it off; leave it in 
the standard library but expunge all mention of it and maybe add a 
warning to let the unwary know it's duff.

Anyway, let's not lose site of the big picture: what really matters 
is to change the rules so this kind of nonsense doesn't happen again. 
Do you agree with that?


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

No, I wanted a Python OSA component. Different thing. The only person 
I know was asking for an OSA wrapper was Donovan, and he went off to 
work on Nevow yonks ago and AFAIK never did anything with it.


>It's partially your fault for not testing it *before* final release.

No, don't you try dumping this on me. It's _entirely_ the fault of 
whoever decided to include an untested module in the standard 
library. Doesn't matter if there's a hundred or a thousand or a 
million people screaming for it; doesn't matter how loud they scream, 
throw tantrums or turn blue in the face. As I already said, it's 
really simple: if nobody cares about it enough to test it then don't 
put it in. No exceptions.

Look, if I submitted a completely unused, untested and potentially 
broken module for inclusion in the standard library I'd be told to 
get lost and not come back until I'd fully addressed that, and quite 
right too. Please tell me the justification for the apparent double 
standard here. In addition, I believe submission rules for the 
standard Python distribution require modules not only to work but 
also be in widespread usage before it'll even get looked at. Why 
should MacPython not be following this rule too?

This is not personal: I'm not looking for blood, to cause 
embarassment, assign guilt, score petty points, etc. I am simply 
trying to show there is an ongoing problem here that folk should 
acknowlege and try to address.


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

It could if you just punted the _entire_ Carbon namespace into 
MacAll. Or are there dependencies in the core Python framework that 
prevent this? And if there is, hell, why not just deprecate the whole 
thing and create a new 'carbon' namespace in MacAll and tell folk to 
use that in future? You might never get rid of Carbon, but at least 
it'll get it sufficiently out the way for a clean new officially 
sanctioned version to set up shop.


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

"MacPython: We've all this great Mac-specific stuff, but we won't 
tell you how to use any of it. Also, quite a bit of it is broken 
because we couldn't be bothered to do do a decent job of it." This is 
not the way to make a great impression with users. And really, what 
is the point of wasting valuable time and effort doing a half-assed 
job? It could be spent much more profitably elsewhere doing something 
more productive: writing modules you actually care about yourself, 
providing better documentation for existing modules, spending time 
with the kids, getting pleasantly hammered down the pub, etc.

And it does matter, because sooner or later folk will want to use 
Mac-specific features either directly or indirectly - it's one of the 
reasons for choosing MacPython in the first place. It's the same BS 
that Apple pull with AppleScript: looks ultra-tasty from the outside, 
but some munching later and you start to realise there's this really 
really bad taste in your mouth, plus a wriggling sensation you don't 
even want to think about. Apple are just a bunch of classy tarts only 
interested in my wallet, but I expect better from the honest and 
hardworking artisans behind MacPython. And I expect the folk at the 
top - the ones directly responsible for the project's current and 
future well-being - to be the most stringent, selective and 
disciplined of all.

has
-- 
http://freespace.virgin.net/hamish.sanderson/