I come to praise .join, not to bury it...

Donn Cave donn at u.washington.edu
Tue Mar 6 14:36:38 EST 2001


Quoth "John W. Baxter" <jwbnews at scandaroon.com>:
| With luck and good will, we ought not have so many of this sort of 
| discussion after the fact in the future.
|
| We now have the PEP process...and the discussion of the PEP is the right 
| place for alarms to be raised, both technical ("that fails when...") and 
| otherwise ("I'd rather see this than that.").

Actually I think that may be representative of a misunderstanding about
what's going on here.  I don't think I have seen a many posts in this
branch of threads that took the position, in so many words, that the
features in question shouldn't have been implemented in Python.  The
ones that have, have taken kind of surprising angles on it, like the
idea that string functions might profitably be omitted from a special
purpose small subset interpreter.  There have been plenty of criticism,
but speaking for myself, if people see a categoric rejection of the
feature there, they're reading something into my words that wasn't in
my head.  That is an easy mistake to make, it's just simplistic.

I would expect that if these same people were herded into a room and
subjected to a PEP discussion, they would neither raise technical
alarm nor suggest better alternatives, and not for lack of imagination
but simply because these features aren't that in kind of trouble.
They more or less make sense, and they're here for more or less valid
reasons.  Yet afterwards, you will read "this is line noise."  Not
because the PEP process failed, it just doesn't address the question
of how to program in Python.  We ought to recognize this landscape
pretty well, because we have seen the Perlites walking through it all
along.  They're acutely conscious of the difference between what the
language can be and what people make of it.  As Python gets richer,
the same forces come to bear on it.  I don't know if we have a choice
to not get richer, it's probably a categorical imperative that is as
silly to resist as the ensuing entropy.  But we can and do occasionally
turn away from a few features that come along, they don't all get into
Python and we always have the choice of how to write our own software.
We don't have a huge problem yet, but it's good to face up to what
little problems we do have.

The threads can get pretty tedious, and it sure is not obvious that
it's a good way to solve any problem.  There is an awful lot of talking
at cross purposes, particularly if you accept my premise that none of
us want to actually repeal the features in question.  But I think there's
some good in it anyway.  Only this morning, when I thought everything
must have been said several times over, someone made a point about
methods and literals, one of those insights that are so obvious in
retrospect I'm kind of embarrassed to admit, which is the sign of a
good point.  I don't want to suppress that kind of thing, because it
helps me think about what I can do to write well.

	Donn Cave, donn at u.washington.edu



More information about the Python-list mailing list