Why do Pythoneers reinvent the wheel?

[Tim Daneliuk]

Stefano Masini wrote:

> On 10 Sep 2005 03:16:02 EDT, Tim Daneliuk <tundra at tundraware.com> wrote:
> 
>>frameworks are unlikely to serve them well as written. I realize this is
>>all at a level of complexity above what you had in mind, but it's easy
>>to forget that a significant portion of the world likes/needs/benefits
>>from things that are *not* particularly generic.  This is thus reflected
>>in the software they write.
> 
> 
> In my opinion this has got more to deal with the open source vs.
> proprietary debate, that I wouldn't like to talk about, since it's
> somewhat marginal.

I think the point I was trying to make was there are times when
a generic factoring of reusable code is unimportant since the code
is so purpose-built that doing a refactoring makes no sense.

> 
> What I was pointing out is well summarized in the subject: Why do
> Pythoneers reinvent the wheel?
> Reinventing the wheel (too much) is Bad for both the open source
> community and industry. It's bad for development in general. I got the

I don't share your conviction on this point.  Reinventing the wheel
makes the wheel smoother, lighter, stronger, and rounder.  Well,
it *can* do this.   Of far greater import (I think) is whether
any particular implementation is fit to run across a breadth of
platforms.  To me, a signficant benefit of Python is that I am
mostly able to program the same way across Unix, Windows, Mac
and so on.

<SNIP>

> If such an aid to _general_ problem solving is indeed missing (I might
> be wrong) from the current state of python, I don't really think the
> reason is related to industry. I would look for reasons elsewhere,
> like it beeing difficult to come out with effective decisional support
> in an open source community, or something like this. I can certainly
> see the challenge of who and how should decide what goes in the
> library, and what not.


This is too abstract for me to grasp - but I admit to be old and feeble ;)

I think what you see today in the standard library are two core ideas:
1) Modules that are more-or-less pass-through wrappers for the common
APIs found in Unix and 2) Modules needed commonly to "do the things that
applications do" like manipulate data structures or preserve active
objects on backing store. If what you want here is for everyone to agree
on a common set of these and stick exclusively to them, I think you will
be sorely disappointed. OTOH, if someone has a better/faster/smarter
reimplementation of what exists, I think you'd find the community open
to embracing incremental improvement. But there is always going to be
the case of what happened when I wrote 'tconfpy'. The existing
configuration module was nice, but nowhere near the power of what I
wanted, so I wrote something that suited me exactly (well ... sort of,
'tconfpy2' is in my head at the moment).  If the community embraced
it as a core part of their work, I'd be delighted (and surprised), but
I don't need for that to happen in order for that module to have value
to *me*, even though it does not displace the existing stuff.


-- 
----------------------------------------------------------------------------
Tim Daneliuk     tundra at tundraware.com
PGP Key:         http://www.tundraware.com/PGP/