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

[Terry Reedy]

"Douglas Alan" <doug at alum.mit.edu> wrote in message 
news:lcr6o7g7zf.fsf at gaffa.mit.edu...
|| But it wasn't based on a "misquote of Tim Peters"; it was based on an
| *exact* quotation of Tim Peters.

My mistake.  The misquotation is in the subject line and other's posts here 
and in other threads.

| > and a mischaracterization of Python

Nonetheless, picking on and characterizing Tim's statement as 
anti-flexibility and un-scientific is to me writing of a sort that I would 
not tolerate from my middle-school child.

I checked the context of the quote, page 3 (and 4) of
http://swiss.csail.mit.edu/classes/symbolic/spring07/readings/robust-systems.pdf

"(3)Indeed, one often hears arguments against building flexibility into an 
engineered system.
For example, in the philosophy of the computer language Python it is 
claimed:
'There should be one - and preferably only one - obvious way to do it.'[25]
Science does| not usually proceed this way: In classical mechanics, for 
example, one
can construct equations of motion using Newtonian vectoral mechanics, or 
using a
Lagrangian or Hamiltonian variational formulation.[30] In the cases where 
all three approaches are applicable they are equivalent, but each has its 
advantages in particular contexts."

This footnote is in the context of a section discussing redundancy in 
biological systems (and the usual lack thereof in engineered physical 
systems).  Python is an algorithm language and a tool used to engineering 
information systems, which is something different.  The next sections are 
about exploratory behavior.  Languages do not 'behave', let alone 
'explore'.

Leaving that aside, if you consider vector mechanics and variational 
formulations as roughly analogous to functional versus procedural 
programming (or OOP), then Python has both (or all three).  Or if you 
consider them to be different languages for expressing and solving 
problems, then Python is one just language, but one that intentionally 
works well with some others.  So Python seems to have the sort of 
flexibility that he implicitly claims it does not.

The general problems of software inflexibility that he mentioned in a 
previous section have nothing specific to do with Python.

When he gets to solutions, one long section (page 13) somewhat specific to 
languages, versus applications thereof, is about extensible generic 
operations "where it is possible to define what is meant by addition, 
multiplication, etc., for new datatypes unimagined by the language 
designer."  Well, golly gee.  Guess what?  Not only is Python code generic 
unless specialized (with isinstance tests, for instance), but it is highly 
extensible for new datatypes, just as Sussman advocates.  There is a 
special method for just about every syntactic construct and builtin 
function.  And 3.0 may add a new generic function module to dispatch on 
multiple arguments and possibly predicates.

But what naive reader could possibly guess any of this from the single 
mention of Python quoted above?

Terry Jan Reedy