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/ _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
