Why do Pythoneers reinvent the wheel?

[konrad.hinsen at laposte.net]

Stefano Masini wrote:

> There are a few ares where everybody seems to be implementing their
> own stuff over and over: logging, file handling, ordered dictionaries,
> data serialization, and maybe a few more.
> I don't know what's the ultimate problem, but I think there are 3 main reasons:
> 1) poor communication inside the community (mhm... arguable)
> 2) lack of a rich standard library (I heard this more than once)
> 3) python is such an easy language that the "I'll do it myself" evil
> side lying hidden inside each one of us comes up a little too often,
> and prevents from spending more time on research of what's available.

I'd like to add one more that I haven't seen mentioned yet: ease of
maintenance and distribution.

Whenever I decide to use someone else's package for an important
project, I need to make sure it is either maintained or looks clean
enough that I can maintain it myself. For small packages, that alone is
often more effort than writing my own.

If I plan to distribute my code to the outside world, I also want to
minimize the number of dependencies to make installation simple enough.
This would only stop being a concern if a truly automatic package
installation system for Python existed for all common platforms - I
think we aren't there yet, in spite of many good ideas. And even then,
the maintenance issue would be even more critical with code distributed
to the outside world.

None of these issues is specific to Python, but with Python making new
developments that much simpler, they gain in weight relative to the
effort of development.

> It seems to me that this tendency is hurting python, and I wonder if
> there is something that could be done about it. I once followed a

I don't think it hurts Python. However, it is far from an ideal
situation, so thinking about alternatives makes sense. I think the best
solution would be self-regulation by the community. Whenever someone
discovers three date-format modules on the market, he/she could contact
the authors and suggest that they sit together and develop a common
version that satisfies everyone's needs, perhaps with adaptor code to
make the unified module compatible with everyone's individual modules.

Konrad.