<div dir="ltr">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.<div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 20, 2015 at 11:30 AM, Erik Bray <span dir="ltr"><<a href="mailto:erik.m.bray@gmail.com" target="_blank">erik.m.bray@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Jul 14, 2015 at 6:22 PM, Robert Collins<br>
<<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>> wrote:<br>
> For clarity, I think we should:<br>
>  - remove the assret check, it is I think spurious.<br>
>  - add a set of functions to the mock module that should be used in<br>
> preference to Mock.assert*<br>
>  - mark the Mock.assert* functions as PendingDeprecation<br>
>  - in 3.6 move the PendingDeprecation to Deprecated<br>
>  - in 3.7 remove the Mock.assert* functions and the check for method<br>
> names beginning with assert entirely.<br>
<br>
</span>Hi all,<br>
<br>
I'm just an onlooker, and haven't read every word of this thread.  In<br>
fact I worry that it's pointless to reply to rather than starting a<br>
new thread.  I just wanted to make sure that the specific message I'm<br>
replying too wasn't lost in the noise because I think Robert's<br>
suggestion makes vastly more sense than anything else I've seen here<br>
(I came searching through the thread to see if anyone else suggested<br>
this before I started a thread to do so).<br>
<br>
I don't think it makes any sense to have magic assert_ methods on the<br>
Mock object.  Not only does the "magic" clearly lead to too many<br>
ambiguities and other problems--I think they make less sense from an<br>
API standpoint in the first place.  Typically asserting something in a<br>
test is not something an object *does*--a method.  More often we as a<br>
test writers assert something *about* an object.  The assertion is an<br>
external tool meant to measure and introspect things about the system<br>
under observation.  In this case, although Mock is itself a testing<br>
tool, we're introspecting something about the Mock object as external<br>
observers.<br>
<br>
***Assertions on Mock objects should be implemented as stand-alone<br>
functions (that happen to be used primarily on Mock objects as<br>
input).***<br>
<br>
Aside from, in my mind, making more sense philosophically, using<br>
specialized assert functions for this has absolutely none of the<br>
spelling ambiguities or other problems of the magic methods.<br>
<br>
I'm -0 on removing the assret_ methods unless no one is using them<br>
yet.  I don't care if they're there as long as they're deprecated<br>
along with the other magic methods of Mock.<br>
<br>
Best,<br>
Erik<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/bobcatfish%40gmail.com" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/bobcatfish%40gmail.com</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Christie Wilson</div></div>
</div>