When mocking a class with patch, passing in spec=True, the mock class
has an instance created from the same spec. Should this be the default
behaviour for mocks anyway (mock return values inheriting the spec from their
parent), or should it be controlled by an additional keyword argument
(inherit) to the Mock constructor?

Interaction of magic methods with spec, wraps. For example, should spec cause
all methods to be wrapped with mocksignature perhaps? (or another keyword
argument perhaps?)

Should magic method calls (including __call__?) be tracked in method_calls?

Could take a patch keyword argument and auto-do the patching in the
constructor and unpatch in the destructor. This would be useful in itself, but
violates TOOWTDI and would be unsafe for IronPython (non-deterministic calling
of destructors). Destructors aren’t called anyway where there are cycles, but
a weak reference with a callback can be used to get round this.

Mock has several attributes. This makes it unsuitable for mocking objects
that use these attribute names. A way round this would be to provide start
and stop (or similar) methods that hide these attributes when needed.
(_name is a mock attribute that will be not-uncommon, but it is accessed
externally on mocks when building method_calls names and so can’t be changed
to a double underscore name.)

If a patch is started using patch.start and then not stopped correctly, due
to a bug in the test code, then the unpatching is not done. Using weak
references it would be possible to detect and fix this when the patch object
itself is garbage collected. This is tricky to get right though.

side_effect is now called with the same arguments as the mock is called with and
if returns a non-DEFAULT value that is automatically set as the mock.return_value.

wraps keyword argument used for wrapping objects (and passing calls through to the wrapped object).

Mock.reset renamed to Mock.reset_mock, as reset is a common API name.

patch / patch_object are now context managers and can be used with with.

A new ‘create’ keyword argument to patch and patch_object that allows them to patch
(and unpatch) attributes that don’t exist. (Potentially unsafe to use - it can allow
you to have tests that pass when they are testing an API that doesn’t exist - use at
your own risk!)

The methods keyword argument to Mock has been removed and merged with spec. The spec
argument can now be a list of methods or an object to take the spec from.

Nested patches may now be applied in a different order (created mocks passed
in the opposite order). This is actually a bugfix.

patch and patch_object now take a spec keyword argument. If spec is
passed in as ‘True’ then the Mock created will take the object it is replacing
as its spec object. If the object being replaced is a class, then the return
value for the mock will also use the class as a spec.

A Mock created without a spec will not attempt to mock any magic methods / attributes
(they will raise an AttributeError instead).