Nick Coghlan <ncogh...@gmail.com> writes: > On 17 July 2015 at 08:30, Ben Finney <ben+pyt...@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 > "assret_*".
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 from that. > 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 | Ben Finney _______________________________________________ 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
