Replace hand-written Mock-class with unittest.mock.MagickMock in the FAQ trick for 'autodoc`

[ankostis]

I'm suggesting to improve the exemplary code of the trick needed to make the autodoc sphinx-extension work with dependencies needing C-libraries:
http://read-the-docs.readthedocs.org/en/latest/faq.html#i-get-import-errors-on-libraries-that-depend-on-c-modules

Instead of including a half-baked mock-class why not use the readily unittest.mock.MagickMock?
That way we get 2 gains:

1. A much smaller code, and
2. the mocked modules work OK more often.

Here is the code i'm suggesting:

MOCK_MODULES = ['semantic_version', 'numpy']
from unittest import mock
sys.modules.update((mod_name, mock.MagicMock()) for mod_name in MOCK_MODULES)

The drawback is that the fix applies only for python 3.3+.1

I can request a merge if instructed on how to explain to the developers the python 3.3+ issue.

[ericholscher]

Sounds like a good idea. Is this backported to 2.x do you know?

[jodal]

unittest.mock in Python 3.3 is the same as the mock package from PyPI, which works for all relevant Python versions.

[ericholscher]

Cool. Would happily merge this if a PR was sent. Working on some other stuff today, but it sounds like a win.

[ankostis]

Please do not merge my request, it has a minor error in the python code (MagicKMock instead of MagicMock :-(

[ankostis]

Well, although the MagicMock does a lost things better, it does not "behave" as package, as the class method of the previous code did.

So now I believe that i have nailed it:

from unittest.mock import MagicMock

class Mock(MagicMock):
    @classmethod
    def __getattr__(cls, name):
            return Mock()

I' preparing the patch.

[ericholscher]

Thanks for this :)