[Python-Dev] How far to go with user-friendliness
robertc at robertcollins.net
Tue Jul 14 21:27:14 CEST 2015
On 15 July 2015 at 02:06, Paul Moore <p.f.moore at gmail.com> wrote:
> On 14 July 2015 at 14:51, Florian Bruhin <me at the-compiler.org> wrote:
>> * Steven D'Aprano <steve at pearwood.info> [2015-07-14 23:41:56 +1000]:
>> With the patch, an AttributeError is raised if you call something
>> starting with assert or assret instead.
> In retrospect, this seems like a mistake in the design. Much like
> namedtuple, mocks should carefully separate "actual" methods from
> mocked ones (in the case of namedtuple, from tuple element names). If
> Guido would let us use the time machine, I'd argue that maybe the
> special methods should be _assert_called_with (or something similar).
I'd go further and just separate the APIs.
mock.assert_called_with(a_mock, *args, **kwargs)
mock can know how to poke under the covers (e.g. using
__Mock_assert_called_with) without leaking it into the users objects.
> Given that it's way too late to take that path, I can see the value of
> trying to detect common errors. Particularly as the result of failing
> to do so is an apparently-passing test.
We can add a new API and gradually deprecate the old one. With the
presence of 'mock' as a rolling backport, this can be used by folk on
Python 3.3 and 3.4 so they don't get locked into one release of Python
> In effect, this patch is "reserving" all attributes starting with
> "assert" or "assret" as actual methods of the mock object, and not
> mocked attributes.
Yes, and thats ugly. OTOH it caught hundreds of useless tests in
OpenStack when this got ported into mock 1.1.0.
> Reserving "assert" seems fair.
> Reserving "assret" seems odd, as people say why just this
> mis-spelling? Is there any specific evidence that this typo happens
> more often "in the wild" than any other? Given that the original issue
> was raised by Michael Foord (the author of mock), I'd be inclined to
> assume that he'd encountered evidence to that effect.
> So ultimately I'm +1 on reserving "assert" (given that a more radical
> fix isn't possible) and +0 on adding "assret" (simply on the basis
> that someone more knowledgeable than me says it makes sense).
Since assret is solely a 'you may not use this' case, I think we can
remove the check for that quite trivially, at any point we want to.
Robert Collins <rbtcollins at hp.com>
HP Converged Cloud
More information about the Python-Dev