[Python-Dev] How far to go with user-friendliness
ben+python at benfinney.id.au
Sat Jul 18 02:39:17 CEST 2015
Nick Coghlan <ncoghlan at gmail.com> writes:
> On 17 July 2015 at 08:30, Ben Finney <ben+python at benfinney.id.au> wrote:
> > By definition, advocating to not add cruft to an API is going to be in
> > advance of being bitten by those additions.
> That's not what people are doing. Folks are actually arguing for
> *restoring* the ability to mock out method names starting with
You're describing a fait accompli. That doesn't justify the changes to
get to that fait.
I'm pointing out that what you call a situation to be “restored” is what
we've got now, and a change away from that – to add a DWIM alias for one
typo, seemingly arbitrary among typos – needs sufficient justification.
I'm also pointing out that clarity and similicity of API is sufficiently
important that there needs to be a strong benefit to justify moving away
> I still don't know why anyone thinks restoring that would be a
> worthwhile use of a maintainers' time (or why they thinking arguing in
> favour of such a capability is a worthwhile use of theirs).
Just as easily, I could express surprise that adding DWIM aliases for
some typos and not others has somehow been thought worthwhile of the
maintainers's time. But in neither case does that argue for or against,
so I don't think that's terribly germane to the discussion.
> None of the perspectives presented in this thread are new
Must they be new? I don't see how that matters. If they haven't been
adequately addressed, it shouldn't matter how new they are; they're
still salient objections to a change when it is announced.
\ “In any great organization it is far, far safer to be wrong |
`\ with the majority than to be right alone.” —John Kenneth |
_o__) Galbraith, 1989-07-28 |
More information about the Python-Dev