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 thread. Steve _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
