Lambda: the Ultimate Design Flaw

[Terry Reedy]

"Aahz" <aahz at pythoncraft.com>

> Pinard  <pinard at iro.umontreal.ca> 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