[Python-Dev] How far to go with user-friendliness

Florian Bruhin me at the-compiler.org
Sun Jul 19 20:33:55 CEST 2015


* Ron Adam <ron3200 at gmail.com> [2015-07-19 11:17:10 -0400]:
> I had to look at the source to figure out what this thread was really all
> about.
> 
> Basically it looks to me the purpose of adding "assret" is to add an "alias
> check" for "unsafe" methods.  It doesn't actually add an "alias".  It allows
> a developer to use a valid alias to avoid conflicting with methods starting
> with assert that will still work with the mock module.
> 
> The mock module says that when "unsafe" flag is set to True, it will not
> raise AssertionError for methods beginning with "assert" and "assret".  It
> doesn't specify what "unsafe" means, and why you would want to do that.
> 
> So first do this...
> 
>     * Document "unsafe" in mock module.

The issue is that Mock objects (if not using spec/autospec) allow
*any* method to be called, and return another mock:

    >>> m = mock.Mock()
    >>> m.foo()
    <Mock name='mock.foo()' id='140277502245632'>

But they *also* have some special methods to check if they have been
called:

    >>> m.assert_called_with()
    [...]
    AssertionError: Expected call: mock()
    Not called

But if you do a typo, the test silently doesn't fail (because it's returning a
new mock instead of checking if it has been called):

    >>> m.assert_called()
    <Mock name='mock.assert_called()' id='140277467876152'>

With the patch, everything starting with "assert" or "assret" (e.g. my
example above) raises an AttributeError so these kind of issues can't
happen.

The thing people are discussing about is whether this should also
happen if you do "m.assret_called_with()" (i.e. if this is a common
enough typo to warrant a special exception), or if *only* things
starting with assert_* are checked.

The merged patch also treats "assret_*" as a typo, and some people
think this is a wart/unnecessary/harmful and only "assert_*" should
raise an AttributionError, i.e. the patch should be amended/reverted.

> I presume "unsafe" in this case means the method will not fail if an
> optimise flag is used because an assert in an assert method will not fail.
> 
> The problem I see is checking for "assert" by name convention is dubious to
> start with.  An method that begins with assert may not actually use
> "assert", and one's that don't may possibly use it.
> 
> A better way is to have a function in the inspect module that will return
> True if a function uses the "assert" keyword.
> 
> That is trickier than it sounds, because the optimize flag causes the
> asserts to be removed.  So it may require setting a flag on a function if
> it's source contained "assert".
> 
> With a reliable test for "assert", the check for an naming convention alias
> is not needed.
> 
> 
> If I've still not quite got the gist of this issue, the please correct me.

This has nothing to do with the assert *keyword* or optimization -
only with the behaviour of mock and its "assert_*" methods.

I hope this clears things up!

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150719/2fb2deae/attachment-0001.sig>


More information about the Python-Dev mailing list