Alias IPython extension

I’m fed up of (mis)typing %load_ext kedro.extras.extensions.ipython. Let’s make everyone’s lives a bit easier and alias it.

Previously we had said that %load_ext kedro.ipython would be an improvement, but I’m going to make a drastic suggestion and go even further to suggest %load_ext kedro. If you’re doing %load_ext anyway then you know it’s an IPython extension so the ipython part is just unnecessary extra characters.

How?

Really just one line of code in kedro/__init__.py that says:

from .extras.extensions.ipython import load_ipython_extension

This should turn the module kedro into an IPython extension without affecting any of the existing kedro functionality.

Is that it?

No! This is the important part. As per discussion we had as part of https://github.com/kedro-org/kedro/issues/712 we need to make sure that this import doesn’t have undesired side effects, since the above line of code will run every time anyone imports anything from kedro. This means that any imports in the extras -> extensions -> ipython import chain will also be executed.

There are three possible risks here:

• the import tries to import something that is not a core dependency of kedro and the user doesn’t have (which includes IPython!)
• the import imports loads of things that exist but makes things very slow
• the import has side effects that we don’t want to be executed (e.g. importing from kedro.framework.project import LOGGING actually configures logging)

All three risks here should be mitigated against because in https://github.com/kedro-org/kedro/pull/1761 I already hid all the non-standard library imports inside functions as a guard. So, unless I missed something, what you need to do is write some tests to ensure that this does not get accidentally broken in the future. Something like these (will need some cunning mocking):

• import kedro does not try to import IPython
• import kedro does not do imports like from kedro.framework.project import LOGGING

Obviously manually test all this too, but the important thing here is writing the automated tests so it doesn’t break in future if someone moves an import to be unguarded at the top level of the ipython.py file.

Anything else to do?

Yes! Update all mentions in the codebase of kedro.extras.extensions.ipython to kedro. This is probably just docs and the kedro ipython/jupyter commands and should be easy. The hard thing here is the writing the tests.

[noklam]

@AntonyMilneQB I think %load_ext kedro makes more sense, my main concerns are the ones you mentioned, once we put it in the top kedro directory it’s very hard to get rid of it since it gets triggered when importing any kedro submodule, but I don’t see a way to get around this so I guess this is the only way.

To your 2nd point, I agree it’s not something we should do now, a separate issue to keep this discussion alive is ideal👍🏼

[AntonyMilneQB]

Yeah, in this case I don’t think it’s a problem that the import is triggered whenever we import anything from kedro. I thought of three possible risks here, as detailed in the top post, but I think none of them will be a problem here. Please do shout if there’s any other risks I didn’t think of though.