On 15 July 2015 at 02:06, Paul Moore <p.f.mo...@gmail.com> wrote: > On 14 July 2015 at 14:51, Florian Bruhin <m...@the-compiler.org> wrote: >> * Steven D'Aprano <st...@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).
Well. 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 or another. > 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. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ 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
