[Python-Dev] How far to go with user-friendliness
Christie Wilson
bobcatfish at gmail.com
Mon Jul 20 20:48:20 CEST 2015
I am terrified of replying to this thread since so many folks on it seem
unhappy that it is continuing, but I want to +1 what Erik said.
Robert's solution is downright inspiring in how it gets to the heart of the
problem that the assret/assert feature is trying to address, and as a
frequent user of mock, I very much would like to see it implemented.
On Mon, Jul 20, 2015 at 11:30 AM, Erik Bray <erik.m.bray at gmail.com> wrote:
> On Tue, Jul 14, 2015 at 6:22 PM, Robert Collins
> <robertc at robertcollins.net> wrote:
> > For clarity, I think we should:
> > - remove the assret check, it is I think spurious.
> > - add a set of functions to the mock module that should be used in
> > preference to Mock.assert*
> > - mark the Mock.assert* functions as PendingDeprecation
> > - in 3.6 move the PendingDeprecation to Deprecated
> > - in 3.7 remove the Mock.assert* functions and the check for method
> > names beginning with assert entirely.
>
> Hi all,
>
> I'm just an onlooker, and haven't read every word of this thread. In
> fact I worry that it's pointless to reply to rather than starting a
> new thread. I just wanted to make sure that the specific message I'm
> replying too wasn't lost in the noise because I think Robert's
> suggestion makes vastly more sense than anything else I've seen here
> (I came searching through the thread to see if anyone else suggested
> this before I started a thread to do so).
>
> I don't think it makes any sense to have magic assert_ methods on the
> Mock object. Not only does the "magic" clearly lead to too many
> ambiguities and other problems--I think they make less sense from an
> API standpoint in the first place. Typically asserting something in a
> test is not something an object *does*--a method. More often we as a
> test writers assert something *about* an object. The assertion is an
> external tool meant to measure and introspect things about the system
> under observation. In this case, although Mock is itself a testing
> tool, we're introspecting something about the Mock object as external
> observers.
>
> ***Assertions on Mock objects should be implemented as stand-alone
> functions (that happen to be used primarily on Mock objects as
> input).***
>
> Aside from, in my mind, making more sense philosophically, using
> specialized assert functions for this has absolutely none of the
> spelling ambiguities or other problems of the magic methods.
>
> I'm -0 on removing the assret_ methods unless no one is using them
> yet. I don't care if they're there as long as they're deprecated
> along with the other magic methods of Mock.
>
> Best,
> Erik
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/bobcatfish%40gmail.com
>
--
Christie Wilson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150720/a0d9aefc/attachment.html>
More information about the Python-Dev
mailing list