"Douglas Alan" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] || 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 -- http://mail.python.org/mailman/listinfo/python-list
