<div dir="auto">A stricter mock object cannot be a bad idea :-) I am not sure about your proposed API: some random code may already use this attribute. Maybe it can be a seal (mock) function which sets a secret attribute with a less common name?<div dir="auto"><br></div><div dir="auto">Yeah, please open an issue on <a href="http://bugs.python.org">bugs.python.org</a> ;-)</div><div dir="auto"><br></div><div dir="auto">Victor</div><div dir="auto"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">Le 29 mai 2017 11:33 PM, "Mario Corchero" <<a href="mailto:mariocj89@gmail.com">mariocj89@gmail.com</a>> a écrit :<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello Everyone!<br><br>First time writing to python-ideas.<br><br><b>Overview</b><div>Add a new mock class within <a href="https://github.com/python/cpython/blob/master/Lib/unittest/mock.py" target="_blank">the mock module</a>, SealedMock (or RestrictedMock) that allows to restrict in a dynamic and recursive way the addition of attributes to it. The new class just defines a special attribute "sealed" which once set to True the behaviour of automatically creating mocks is blocked, as well as for all its "submocks".<br>See <a href="https://github.com/mariocj89/sealedmock/blob/master/README.md" target="_blank">sealedmock</a>. Don't focus on the implementation, it is ugly, it would be much simpler within <i>mock.py</i>.<br><br><div><b>Rationale</b></div></div><div>Inspired by <a href="https://github.com/google/googletest/tree/master/googlemock" target="_blank">GMock</a> RestrictedMock, SealedMock aims to allow the developer to define a narrow interface to the mock that defines what the mocks allows to be called on.</div><div>The feature of mocks returning mocks by default is extremely useful but not always desired. Quite often you rely on it only at the time you are writing the test but you want it to be disabled at the time the mock is passed into your code, that is what SealedMock aims to address.</div><div><br></div><div>This solution also prevents user errors when mocking incorrect paths or having typos when calling attributes/methods of the mock.<br>We have tried it internally in our company and it gives quite a nicer user experience for many use cases, specially for new users of mock as it helps out when you mock the wrong path.</div><div><br></div><div><b>Alternatives</b><br><ul><li>Using auto_spec/spec is a possible solution but removes flexibility and is rather painful to write for each of the mocks and submocks being used.<br></li><li>Leaving it outside of the mock.py as it is not interesting enough. I am fine with it :) just proposing it in case you think otherwise.<br></li><li>Make it part of the standard Mock base class. Works for me, but I'd concerned on how can we do it in a backward compatible way. (Say someone is mocking something that has a "sealed" attribute already).</li></ul>Let me know what you think, happy to open a enhancement in <a href="https://bugs.python.org/" target="_blank">https://bugs.python.org/</a> and send a PR.<br><br>Regards,<br>Mario</div></div>
<br>______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>
<br></blockquote></div></div>