Kill process to solve the reload modules problem. And what about module D, which also imports C and is using its global objects? IPython's autoreload tries to address these issues, but is a bit fragile for reasons such as the ones I just described. But there's also a strong argument to be made that this would be intrusive and surprising. There's a strong argument to be made that unless all the others are reloaded too, that you could end up with inconsistent object state between modules. Suppose main imports A imports B imports C, and you edit B. Remember that when you reload a module, it loses all its global state. Second, it's not clear exactly what implementation would be most useful. So this would need to be an IPython enhancement, not just a Canopy one. Run, cd, edit, and the GUI debugger, occur through the IPython magics and/or API. First, recall that the Canopy GUI's Python is quite strictly an IPython QTConsole. Phillip, this is certainly an appealing idea, but the details would be tricky. Note: IPython's %reset magic command clears the user namespace but does not restart the kernel, so cannot reverse existing imports, so is not an effective workaround for this issue. See including the important caveats at the bottom of the page. because they must be initialized as part of your edited module's initialization), ipython's autoreload extension can be useful. It is described briefly in this discussion on Stack Overflow and elsewhere online in more detail.ģ) For more complex cases, where reloading the module that you have edited also requires that its dependent/imported modules be reloaded (e.g.
In many cases, this suffices after editing a module. Starting with Python 3.4, it is imported from standard module "importlib"). But this has downsides as well, notably losing the data which exists in your ipython namespace and in any other imported modules.Ģ) For simple cases, you can use python's reload function. There are several ways to work around this issue.ġ) The simplest and most certain is to restart the ipython kernel after changing an imported module. by using ipython to run a program which uses it), python will think "I've already imported this module, no need to read that file again", so your changes will not be effective. (Note that this does not apply to your main program file, which IPython runs directly, rather than importing, so that changes are always effective once they are saved.) In particular, if you change a python module which has already been imported within ipython, and then re-import that module (e.g. However this great feature can have puzzling consequences, especially to programmers who are more used to compiled languages with make-style dependency change detection. Therefore once a module is imported, it stays imported, and re-importing it has no effect at all. In order to provide this functionality, the modules which hold your data remain alive between invocations. A powerful feature of Jupyter / IPython (indeed, of Python itself) is that you can interact with your data from the (I)Python command line.
0 kommentar(er)
