Python's "only one way to do it" philosophy isn't good?

Terry Reedy tjreedy at udel.edu
Thu Jun 21 20:04:50 EDT 2007


"Steven D'Aprano" <steven at REMOVE.THIS.cybersource.com.au> wrote in message 
news:pan.2007.06.21.10.19.47 at REMOVE.THIS.cybersource.com.au...
| On Wed, 20 Jun 2007 17:23:42 -0400, Douglas Alan wrote:
| > Macros are a way to abstract syntax the way that objects are used to
| > abstract data types and that iterators and generators abstract control,
| > etc.
|
| But why is the ability to abstract syntax good?

I think this points to where Sussman went wrong in his footnote and Alan in 
his defense thereof.  Flexibility of function -- being able to do many 
different things -- is quite different from flexibility of syntax -- being 
to say 'do this' many different ways.  An system with a limited repetoire 
of actions could have multiple ways to invoke each.  But it would still be 
limited and inflexible in respect to what it can do.

Sussman's essay advocates functional flexibility.  So when he claims that 
some advocate against 'flexibility', I think it entirely reasonable to read 
that as 'operational flexibility'.  But when he present Peters (and Python) 
as being against [operational] flexibility, he is wrong.  Tim's main 
sentence is "There should be one obvious way to do it" where 'it' is 
anything one might sensibly want to do in real-life code.  That to me is 
advocacy of flexibility and not the opposite.  The parenthetical insertion 
'-- and  preferably only one --' is advocacy against needless# *semantic* 
duplication and is in no way a statement against *functional* flexibility. 
(In particular, the clause is, I believe, meant to differentiate Python 
from a certain other language which purportedly has a 'many ways is good' 
philosophy ;-)

The followup line is 'Although that way may not be obvious at first unless 
you're Dutch'.  It marks the piece as something other than a serious 
academic philosophical dissertation.  Tim Peters is also Mr. [fractional] 
Wink.

Terry Jan Reedy







More information about the Python-list mailing list