Interfaces: use more lazy imports, restore top-level functions maxima_console etc.

[jhpalmieri]

Various files in sage/interfaces/ have this pattern:

class Octave(...):
    ....

octave = Octave()

When combined with from .octave import Octave, octave in sage/interfaces/all.py, this means that an instance of Octave is created when Sage starts up. I think we should avoid this with lazy imports.

Depends on #16522

Component: interfaces

Author: John Palmieri

Branch: 09f5d92

Reviewer: Matthias Koeppe

Issue created by migration from https://trac.sagemath.org/ticket/34547

[mkoeppe]

comment:1

+1

[jhpalmieri]

Branch: u/jhpalmieri/lazy_imports_for_interfaces

[sagetrac-git]

Commit: b483758

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

b483758

trac 34547: use lazy imports in much of sage.interfaces.all

[jhpalmieri]

comment:4

Here is a first attempt. I'll mark it as ready for review, but I am certainly open to changes. If I made changes for the imports for magma and polymake, I got problems with pickling, so I have left those as they were before.

[jhpalmieri]

comment:5

Regarding the change

-interfaces = ['gap', 'gap3', 'giac', 'gp', 'mathematica', 'gnuplot', \
-              'kash', 'magma', 'macaulay2', 'maple', 'maxima', \
-              'mathematica', 'mwrank', 'octave', 'r', \
-              'singular', 'sage0', 'sage']

Do we need to deprecate this before just removing it? I don't know what purpose it was supposed to serve, except perhaps it is the remnants of some old code that once looped through it.

[sagetrac-git]

Changed commit from b483758 to 250da03

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

250da03

trac 34547: use lazy imports in much of sage.interfaces.all

[jhpalmieri]

Description changed:

--- 
+++ 
@@ -6,5 +6,5 @@
 
 octave = Octave()
 ```
-When combined with `from .octave import Octave, octave` in sage/interfaces/all.py`, this means that an instance of `Octave` is created when Sage starts up. I think we should avoid this with lazy imports.
+When combined with `from .octave import Octave, octave` in `sage/interfaces/all.py`, this means that an instance of `Octave` is created when Sage starts up. I think we should avoid this with lazy imports.
 

[nbruin]

comment:8

Where do the ".all" namespaces actually get used and for what? Are they just to trigger initialization of modules? Or do people use them to access symbols too? They certainly be importing symbols from them. Especially with lazy imports, that leads to undesirable side-effects (see e.g. #16522):

sage: type(maxima_calculus)
<class 'sage.misc.lazy_import.LazyImport'>
sage: type(sage.calculus.calculus.maxima)
<class 'sage.misc.lazy_import.LazyImport'>
sage: sage.calculus.calculus.maxima is maxima_calculus  # they are the same object
True
sage: maxima_calculus(1)
1
sage: type(maxima_calculus)
<class 'sage.misc.lazy_import.LazyImport'>
sage: type(sage.calculus.calculus.maxima)
<class 'sage.interfaces.maxima_lib.MaximaLib'>

So as you can see, we end up with a LazyImport object bound in two places. Calling it removes one of the shims but not the other (it can't! it doesn't have a reference to the relevant namespace!).
This object rebinding is only tried upon the first resolution of the lazy object, but it does mean that the shim in the wrong location stays in place (and these shims are not perfect replacements for their objects)

The delayed instantiation of interfaces is laudable but, as you can see, can introduce new problems. What does work is lazy importing the object where you need it, but I'm not so sure we need these objects at the 'all' level. Certainly the from <...>.all import * done in sage.all propagates this problem. The tool clean_namespace at the branch at #16522 can clean it up after import ...