Design-by-Committee

[Grant Griffin]

Andrew Kuchling wrote:
> 
> root at 127.0.0.1 (David) writes:
> > Is the primary focus these days on adding new language
> > features/commands/components, or on cleaning up the existing codebase?
> 
> It seems to mostly be on new language features (iterations,
> generators, unifying types and classes).

It seems like several of the newer things are related to speed.  If I
were to channel Tim channeling Guido here, I would say that he thinks
that making Python nearly as fast as Perl would help put some camels in
the seats <get it?>.

> I think this effort is
> mostly misplaced; raw language features are rarely a reason to choose
> one language over another, the availability of libraries being a more
> critical issue.  Sadly the development team seems to have forgotten
> this.

I agree on libraries.  Of course, Python's large, useful, extremely
well-designed standard library is one of the best reasons to use it, so
anything that enhances that is only for the better.

Although there's a ton of great third-party stuff around, having more of
that stuff in the standard library could be very helpful because it
"blesses" one approach.  Also, of course, it saves users some
installation hassles.

There are downsides to that, of course, namely that third-party stuff
can be released more often than new Python distributions (if that's
possible <wink>).  And it can lead to bloat.  But in cases where
something is high quality, widely used, and stable, making third-party
stuff "standard" might be a very good idea.  (The most obvious example
here is Numerical Python.)

One of the barriers I have in getting people to use my Python code is
that they sometimes have to install several things to make it work. 
When I tell them about that, their eyes tend to glaze over, and they
lose interest.  Heck, just getting them to install Python _itself_ can
be enough of a hurdle (which obviously is why there are several "freeze"
systems out there--including one "standard" one <wink>.)

Still, if I were to channel Tim channeling Guido again, I would say that
adopting things into the standard library constitutes a liability for
the Pythonlabs team in terms of packaging, documentation, and
maintenance.  And that's a problem, given only a small staff.  And
including modules is a one-way trip, like a Roach Motel: "Modules check
in, but they don't check out".  They just live in there forever.  (Oh,
except for "sndex"--or however you spell that module that was just
removed <wink>.)

Perl's CPAN thing seems to be a good compromise: a large number of
third-party modules receive "official" blessing, are centrally organized
and distributed, yet are maintained mostly by their developers.

we-gotta-get-us-one-of-them-things-one-of-these-days-ly y'rs,

=g2
-- 
_____________________________________________________________________

Grant R. Griffin                                       g2 at dspguru.com
Publisher of dspGuru                           http://www.dspguru.com
Iowegian International Corporation            http://www.iowegian.com