Why do Pythoneers reinvent the wheel?

[Stefano Masini]

On 10 Sep 2005 02:10:59 EDT, Tim Daneliuk <tundra at tundraware.com> wrote:
> As someone who implemented their own configuration mini-language
> with validation, blah, blah, blah (http://www.tundraware.com/Software/tconfpy/)

Well, a configuration mini language with validation and blahs is not
exactly what I would call _simple_... :) so maybe it doesn't even fit
into my idea of testing-stdlib, or "quick and dirty" section of the
manual (see my other post).
But certainly it would be worth mentioning in the list of available
solutions under the subsection "Configuration files handling".

> 1) The existing tool is inadequate for the task at hand and OO subclassing
>     is overrated/overhyped to fix this problem.  Even when you override
>     base classes with your own stuff, you're still stuck with the larger
>     *architecture* of the original design.   You really can't subclass
>     your way out of that, hence new tools to do old things spring into
>     being.

That's true, but usually only when the original design if too simple
comparing to the complexity of the problem. Instead a very general
solution can usually be subclassed to easily handle a simpler problem.
You still have to actually understand the general and complex design
in order to be able to write subclasses, so maybe one can be tempted
to punt on it, and write its own simple solution. But in this case it
would just be enough to propose a few solutions in the testing-stdlib:
a) one simple implementation for simple problems, easy to understand,
but limited.
b) one complex implementation for complex problems, 
c) one simplified implementation for simple problems, easy to
understand, but subclassed from a complex model, that leaves room for
more understanding and extension just in case one needs more power.

I fully understand the difficulty of reusing code, as it always forces
you to a learning curve and coming to compromises. But I've also
wasted a lot of time reinventing the wheel and later found stuff I
could have happily lived with if I only had known.

> 2) It's a learning exercise.

Well, so we might as well learn a little more and rewrite os.path, the
time module and pickle. Right? :)

> 3) You don't trust the quality of the code for existing modules.
>     (Not that *I* have this problem :-p  but some people might.)

That's a good point, but it really boils down to being a wise
programmer on one side, being able to discern the Good from the Bad,
and an active community on the other side, able to provide good
solutions and improve them.
If either one is missing, then a lot of bad stuff can happen, and we
can't really take community decisions basing on the assumption that
programmers won't be able to understand, or that the community won't
be able to provide. So we might as well assume that we have good
programmers and an active community.
Which I think is true, by the way!
So, let's talk about a way to more effectively present available
solutions to our good programmers! :)

cheers,
stefano