[Python-Dev] How far to go with user-friendliness

Stephen J. Turnbull stephen at xemacs.org
Mon Jul 20 09:15:32 CEST 2015

Terry Reedy writes:

 > Good (or certainly much better): <I think Nick already tried to fill in 
 > this blank>

I think so too, but IMO Nick and Antoine made a serious mistake by
deprecating this as a "minor design decision" without further
rationale.  That's no excuse at all!  The point of the Zen about
"special cases" is that these minor design decisions are indeed a
slippery slope -- they may be minor individually, but collectively
they lead to real ugliness.  Every one needs to be considered
carefully, and this particular one plays no role in the basic design
of mock -- it's hard to see sufficient "practicality" without context.
Arguing that "special cases aren't" is not like complaining about the
"color of the bikeshed", it's like finding a termite climbing up the
wall and calling for the exterminator.

ISTM that the missing rationale is that the real special case is mock
itself.  Michael referred to this context, but didn't make it
explicit.  Mock effectively "monkeypatches the world".  In that
context, the decision to protect against certain errors whose risk is
greatly increased by mock itself arguably is a *minor* design
decision, and none of the defenders of leaving this feature in 3.5
would consider it a precedent for admitting similar "special cases"
elsewhere in the stdlib.  (Last minute note: I believe this analysis
is confirmed by Florian Bruhin's post, which I don't fully understand.)

I'm not sure I accept that myself<wink/>, but it does convince me that
the feature's defenders continue to firmly believe that special cases
aren't special enough, and that is good enough reason to end the


More information about the Python-Dev mailing list