On 9/9/05, Dave Brueck <[EMAIL PROTECTED]> wrote: > shot). The cost of developing _exactly_ what you need often is (or at least > *appears* to be) the same as or lower than bending to use what somebody else > has > already built.
That's right. But as you say, this is _often_ the case, not always. One doesn't necessarily need to "bend" too much in order to use something that's available out there. If we're talking about simple stuff, like ordered dictionaries, file system management, ini files roundtripping, xml serialization (this one maybe is not that trivial...), I don't think you would have to come to big compromises. I myself reinvented these wheels a few times in different projects, because I wasn't happy with the way I reinvented the first time, then I eventually found some code written by someone else that was _exactly_ the same as my last attempt, my most evolved and "perfect", my prescioussss :), if it wasn't even better. Separate paths of evolution that converged to the same solution, because the problem was simple to begin with. Under this light, it seems to me that I wasted a lot of time. If odict was in the stdlib I wouldn't have bothered writing it. And yet, this code is not available in the stdlib. Sometimes it's not even trivial to be googled for. Plus, if you think of a python beginner, what's the chance that he's gonna say: naa, this code in the library sucks. I'm gonna search google for another ini file round tripper. Whatever is available there, he's gonna use, at least in the beginning. Then he will soon figure out that it indeed sucks, and at that point there's a chance that he'll say: man... _python_ sucks! I cannot even round trip an ini file with the same module! That's why I say this lack of a centralized, officially recommended code repository maybe is hurting python. I agree that building library code is hard because it has to be both correct and simple. But, again, there's a lot of useful stuff not the library, that's simple in the start so it's just a matter of writing it correctly. If the semantics can be different, just provide a couple of alternatives, and history will judge. It would be great if there was a section in the Python manual like this: "Quick and Dirty: Commonly needed tricks for real applications" 1. odict 2. file system management 3. xml (de)serialization 4. ... Each section would describe the problem and list one or a few recommended implementations. All available under __testing_stdlib__. Appoint somebody as the BDFL and make the process of updating the testing stdlib democratic enough to allow for more evolution freedom than the stable stdlib. If such a "quick and dirty" section existed, I think it would also become a natural randevouz point for innovators. If one invented a new cool, simple and useful module, rather than just publishing it in his own public svn repository, he would feel comfortable to start a discussion on the python-testing-stdlib mailing list suggesting to include it in the "quick and dirty" section of the manual. The manual is the primary resource that every python programmer makes use of, expecially beginners. But it is so official that no one would ever dare suggesting to include something in it. If the Vaults of Parnassus were listed in there (maybe a bit trimmed and evaluated first ;) a beginner would have immediate access to the most common tricks that one soon faces when it comes to writing real applications. I'm talking wildly here... I'm quite aware of how simplistic I made it. Just throwing an idea. What do you think? stefano -- http://mail.python.org/mailman/listinfo/python-list
