Why do Pythoneers reinvent the wheel?

[Stefano Masini]

On 9/9/05, Dave Brueck <dave at pythonapocrypha.com> 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