Confusing behavior of hv.extension()

(in an env with matplotlib)

>>> holoviews.extension('no way does this exist')
>>>

(in an env without matplotlib)

>>> holoviews.extension('no way does this exist')
Traceback (most recent call last):
  File "/Users/cball/code/ioam/holoviews4/holoviews/util/__init__.py", line 228, in __call__
    __import__(backend)
ModuleNotFoundError: No module named 'matplotlib'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/cball/Eunectes/mc3/envs/hvdev/lib/python3.6/site-packages/param/parameterized.py", line 1891, in __new__
    return inst.__call__(*args,**params)
  File "/Users/cball/code/ioam/holoviews4/holoviews/ipython/__init__.py", line 106, in __call__
    super(notebook_extension, self).__call__(*args, **params)
  File "/Users/cball/code/ioam/holoviews4/holoviews/util/__init__.py", line 231, in __call__
    "to activate %s extension." % (backend, backend))
TypeError: not enough arguments for format string

[jbednar]

Right, but there’s another level beyond that, due to some monkeypatching in holoviews/__init__.py:

try:
    import IPython                 # noqa (API import)
    from .ipython import notebook_extension
    extension = notebook_extension # noqa (name remapping)
except ImportError as e:
    class notebook_extension(param.ParameterizedFunction):
        def __call__(self, *args, **opts): # noqa (dummy signature)
            raise Exception("IPython notebook not available: use hv.extension instead.")

That way user code is the same whether in or out of the notebook environment, but it does make this code horrible to reason about, and it also makes error detection very awkward.

[jbednar]

To me it seems like this code could be inverted to have one, normal function “extension()” with no monkeypatching, just a try/except import that runs some code in the try, and then runs other stuff in the except.