I think you may be a little hasty here. Also, IPython is not the same as Sage even if Sage uses IPython under the cover (I'm not completely sure it does), and even if the standard Sage REPL looks like a console. So I've been think about Sage. Some of this may also apply to IPython, but maybe not because, as Edward said, it's basically a shell. Of course, this will leave out Windows users; I don't count WSL as being Windows for most users.
Sage, now, it may look like a shell but it can benefit a lot from notebook-like features: 1. After our Sage user goes through various math steps and maybe generates some graphics, now what? He wants to save that work and be able to look at it and pick it up again later! And in the saved work, who wants to save the false starts and the syntax errors? A Leo node differs from a console shell in these ways: you can put the cursor out of sequence and do editing, you can highlight a block and do something with it, you can do something (like recalculate) with the entire node, and you can save and restore it. So here's the user wanting to do Sage. Type *@language sage* at the top. Just like CTRL-B sends the node or a marked part of it to be run as a script, the user can do something similar with lines of Sage code. The node acts much like, but not exactly the same, as a sage console, or the Jupyter Notebook version. Static graphics will be easy to deal with - get Sage to save the graphic to a file and Qt can insert that graphic with a cursor. The graphic can be persisted at that location by having the Sage handler insert an *@image <path>* line; during reload or re-display, the node's code re-inserts the graphic the same way it was originally inserted. Of course, the user doesn't need to know about that. A bonus is that the user could insert any image by manually typing in an *@image* line. Another bonus is that VR3 already understands the *@image* directive. This scenario uses Sage to produce a persistable, editable, rerunable version of the Sage console. 2. Our user wants to do all of the above but add text commentary to explain context or to clarify the work, much as can be done with a Jupyter notebook. So he puts all the Sage work in a section or sections starting with an *@language sag*e directive and ending with an bare *@* character. Leo already has all the machinery for doing this; VR3 works much like this to mix code and non-code. Sage code execution could include either single blocks or all Sage blocks in the node. With this model, we're basically doing literate programming - but live - so we're going back to Leo's roots. 3. As soon as we've gotten Scenario 2 working, the next step would be supporting a whole tree of Sage nodes. Some things need to be worked out, like whether math execution should be restricted to a single node or cover the whole tree. But those are details. Just like the *rst3* command processes an entire tree, a *run-sage* command could process an entire Sage tree. I don't think there is any need to support *@others* since progressive indentation doesn't make much sense for a Sage notebook. VR3 doesn't support it for a similar reason. And I don't thing that <<named sections>> should be supported because they would allow out-of-order execution and rendering, and that could be actively bad. Scenario 3 gets us some of the most used parts of Jupyter notebooks with far lower complexity. It improves on VR3 is some ways (for notebooks, I mean) since the VR3 display is a static, non-editable view. VR3 has the advantage of being able to render an entire tree, while working with Leo nodes as suggested above only lets one look at one node at a time. I think we can live with that. On Sunday, October 20, 2024 at 3:56:41 AM UTC-4 Edward K. Ream wrote: > This Engineering Notebook post discusses integrating Leo with IPython. > Similar remarks apply to Jupyter and SageMath. > > To summarize: *thought experiments doom all such projects.* > > *Bypass IPython's event loop?* > > Suppose Leo avoids creating IPython's event loop. Doing so would avoid > hanging Leo when accessing IPython's features. This idea implies bypassing > IPython's repl. > > *Bypass IPython's repl?* > > Suppose Leo provides IPython's features by accessing them via IPython's > API. However, experiments (and a review of IPython's code) show that > IPython's features require IPython's repl! > > Indeed, IPython's *BaseIPythonApplication *class contains this > description: > > "IPython: an enhanced interactive Python shell." > > *Create a bespoke client-server architecture?* > > Suppose Leo accesses IPython's features by accessing a running instance of > IPython via a client-server architecture. Leo would be the client. It would > be straightforward to start this server when IPython starts. > > But what, exactly, would Leo ask IPython to do? And why would anyone care? > There seems to be no answers to this question! > > *Conclusion* > > The thought experiments presented here suggest that Leo gains nothing by > attempting to work closely with IPython. There are no scenarios in which > Leo gains from accessing IPython's features from within Leo. > > This surprising conclusion is good news. It's always good to abandon > mistaken ideas! > > After clearing our heads, we can see that this conclusion makes sense. Leo > needs no help from IPython and vice versa. Why did we ever think otherwise? > > *Summary* > > Leo's IPython integration does not work and probably has not worked for > years. Yet nobody seems to have noticed! > > Integrating Leo and IPython presents insurmountable problems. All attempts > would likely be complex and fragile, as indeed leoIPython.py has proven to > be. > > Leo gains nothing by attempting to work closely with IPython. All recent > comments from Leonistas support this conclusion. > > Unless I hear convincing counter-arguments, a new PR (scheduled for 6.8.2) > will remove leoIPython.py and Leo's valuespace plugin. There will be no > need to add IPython or Jupyter to Leo's requirements. > > All your comments and questions are welcome. There is plenty of time for > further discussion. > > Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/3588bf88-f9dc-4b73-95e0-8bac4a0dc45an%40googlegroups.com.
