Why do Pythoneers reinvent the wheel?

Stefano Masini stefano at pragma2000.com
Fri Sep 9 17:17:38 CEST 2005

On 8 Sep 2005 08:24:50 -0700, Fuzzyman <fuzzyman at gmail.com> wrote:
> What is pythonutils ?
> =====================
> ConfigObj - simple config file handling
> validate - validation and type conversion system
> listquote - string to list conversion
> StandOut - simple logging and output control object
> pathutils - for working with paths and files
> cgiutils - cgi helpers
> urlpath - functions for handling URLs
> odict - Ordered Dictionary Class

Fuzzyman, your post reminded me of something I can't stop thinking
about. Please don't take this as a critique on your work. I place
myself on the same side of yours.
I just wanted to share this thought with everybody had an opinion about it.

I wonder how many people (including myself) have implemented their own
versions of such modules, at least once in their pythonic life. I
indeed have my own odict (even same name! :). My own pathutils
(different name, but same stuff). My own validate... and so forth.

This is just too bad.
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.

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
discussion about placing one of the available third party modules for
file handling inside the standard library. I can't remember its name
right now, but the discussion quickly became hot with considerations
about the module not being "right" enough to fit the standard library.
The points were right, but in some sense it's a pity because by being
in the stdlib it could have had a lot more visibility and maybe people
would have stopped writing their own, and would have begun using it.
Then maybe, if it was not perfect, people would have begun improving
it, and by now we would have a solid feature available to everybody.

mhm... could it be a good idea to have two versions of the stdlib? One
stable, and one testing, where stuff could be thrown in without being
too picky, in order to let the community decide and improve?

Again, Fuzzyman, your post was just the excuse to get me started. I
understand and respect your work, also because you put the remarkable
effort to make it publicly available.

That's my two cents,

More information about the Python-list mailing list