"Aahz" <[EMAIL PROTECTED]> > Pinard <[EMAIL PROTECTED]> wrote: >>Sure, of course. Yet, our friendly argument is sliding away from was it >>originally was. The point was about not asserting in this forum that >>Python "has only one way to do it", because this is not true anymore. >> >>The principle has been, it may be back in some distant future, but now >>it is not. > > You're conflating two different things: > > * Whether Python currently has only one way to do things > > * Whether Python has a design goal of only one way to do things > > I'll agree that Python currently has many examples of more than one way > to do things (and even Python 3.0 won't remove every example, because > anything more complicated than a Turing Machine has more than one way to > do things). But I won't agree that Only One Way has been abandoned as a > design principle.
The statement in the Zen of Python is "There should be one-- and preferably only one --obvious way to do it." The splits into two related statements: There should be [at least] one obvious way to do it. There should preferably be only one obvious way to do it. Commentary: While 'should' can mean 'must', it can also mean something something softer, like desireability and preference. In Pythonese, it has (as far as I know) such softer meanings, with 'must' used when 'must is meant. In the second sentence, preference is made explicit. The presence of 'obvious' is obviously not accidental. Without it, and with 'should' replaced with 'must', we eventually end up with any of numerous simple, possibly interesting, and mostly practically useless Turing-equivalent systems. The qualifier 'obvious' does not exclude non-obvious ways. For example, the obvious way, in Python, to add 1 and 2 to get 3 is '1+2'. Two non-obvious (certainly for the beginner) ways are '1 .__add__(2)' [space required] and 'import operator; operator.add(1,2)'. Unfortunately, 'obvious' too often get elided in the discussion of this principle. For some, its because it is so obviously needed that it seems to not need to be said. For others, it appears to be because they are not fully cognizant of it. The result can be people talking past each other. And, of course, obviousness is somewhat in the mind of the beholder. The first sentence provides impetus to add new features that 'should be' present but are not. At this point, that mostly means new library modules. The second principle inhibits (but not absolutely prevents) adding 'obvious' redundancy. When exceptions are made, the principle of not breaking code prevents deleting the old except after a while and very occasionally. The inhibitory principle does encourage attempts to relegate the old to a less obvious status by treatments in the tutorial and manuals. The inhibitory principle is certainly still alive. Function decorators barely made it past. The proposal to extend them to classes has so far been rejected by GvR since class decorators seem redundant with metaclasses. And lots else has been ignored or rejected. Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
