Thanks everyone's rapid reply to my proposal!
On Wednesday, May 1, 2019 at 6:55:10 PM UTC+1, Aaron Meurer wrote: > > On Wed, May 1, 2019 at 11:47 AM David Bailey <da...@dbailey.co.uk > <javascript:>> wrote: > . > > The kernel architecture of Jupyter has many advantages, such as > allowing multiple languages. > I am proposing that SymPyFrontend (a proposed alternative name to avoid confusion with Juypiter) will be dedicated to SymPy, so it's inability to handle other languages would not be a real issue. It sends requests to Python/SymPy via C calls to PyRun_SimpleString. > > > I am curious. I have heard many different complaints about the > notebook interface, and I have some of my own. But it sounds like your > issues are different than what I usually hear. > > I would suggest looking a jupyterlab, the new frontend to the > notebook. It's much cleaner and more responsive than the plain > notebook interface. OK - I will look at jupyterlab, but here was my list of objections (uncovered in a few hours of use) relating to the simple Juypiter notebook software. Some of these relate particularly to the classroom context: 1) Juypiter starts up with a list of files, most of which are irrelevant to the user. You have to realise that it is only the .ipynb that should be opened. A Windows program filters an open box to display files of the type required - .ipynb in this case. If you have a file such as foo.doc in Windows, the system knows which software to use to open it, so merely double clicking on that file in the file manager will start the word processor and cause it to open the file in question. Something similar happens with Mathematica .nb files, and it will be easy to achieve this effect with SymPyFrontend (or whatever it is ultimately called). 2) Juypiter opens a CMD box to help it interface to the browser (I don't understand exactly why), and accidentally killing that box messes up the Juypiter session and loses any work. 3) For obvious security reasons, all file I/O is restricted to one pre-specified folder plus its sub-folders. This restriction seems inevitable for a browser based application. It is also not easy to locate where a notebook has been saved for example the heading just says "http://localhost:8888/notebooks/MyNotebook.ipynb"; - not (for example) c:\PythonSystem\Scripts\foo.ipynb I don't know if it would cause a security breach to print the actual path here - or maybe this is unavailable. I was also somewhat concerned about leaving Juypiter running unattended in case it could be hacked in some other way. A standard Windows application need have no such restriction because it cannot read commands from the internet - thus it is possible to open or close any files on the machine to which user has read/write access. 4) After using Jupyter for a while on an existing file I get "The notebook file has changed on disk since the last time we opened or saved it. Do you want to overwrite the file on disk with the version open here, or load the version on disk (reload the page)?" I knew I didn't want to reload the file (destroying my latest work) but neither did I want to write the half finished file back to the disk! I got this wrong on at least one occasion. The random nature of this interruption was particularly unsettling. 5) By experimenting I discovered that In[5] or Out[5] return a string representation of the corresponding input or output - which I thought could be useful - but if an input produced no output - such as "from sympy import *" then typing Out[5] generates this error: KeyError Traceback (most recent call last) <ipython-input-9-57d9ae6d5c76> in <module> I could only figure out what this meant because I knew what I did wrong! 6) I would imagine that beginners may confuse x, the Python variable with x, the SymPy symbol. It might help if SymPyFrontend were (optionally) to track the state of SymPy variables for the user, who could select the variables that should be symbolic or Pythonic using an explicit Windows interface. 7) The Out[5] error message is, of course just one of a number of really hard to understand error messages. This is inevitable because Juypiter submits a request to SymPy, which then processes it with Python code, and something goes wrong. This error message prompted me to realise that a simple syntax scan of each line could be really valuable. For example any input in which (), [], or {} were not correctly paired off could generate a specific error message - indeed my prototype incorporates this feature. Hopefully it will also be possible to pick off many other common faults and provide a message that makes sense to the guy at the far end that just wants to do some maths! 8) I noticed that SageMath maps ^ to ** reversibly (I think), and I was wondering about incorporating an option to do the same. To me using ** to mean exponentiation, harks back to the days of Fortran. I suppose it might be necessary to map ^^ to ^ to cater for anyone who wanted to use the Python * operator. Anyway such a feature would be optional. I used to work on the FTN95 Fortran compiler, and I think the diagnostics that this produces, shows what is possible. 9) Since I have Latex on my machine, I had hoped that Juypiter might allow me to click something and convert any output I desired into the corresponding Latex formula which would sit in place in the notebook. I think this should be possible from within SymPyFrontend. David -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at https://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/63e9cddc-47b7-4e5e-a7cf-ffd29674edc3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
