On Wed, May 1, 2019 at 3:23 PM David Bailey <d...@dbailey.co.uk> wrote: > > 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> 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).
Jupyter lab (and to some degree the old notebook interface) can be used as a full IDE. It has a text editor and extensions can be made to open other types of files. So it makes sense to show every file, not just notebooks. This interface may also come more from a Unix/Mac background where typically file viewers show all files by default. > > 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. I believe there are people who have built more native-like versions of the notebook. I'm not sure what they are or how well they work, especially for Windows. For example, nteract. > > 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! This sounds like a bug. What is the full text from the traceback? Cells should not error when you enter code that isn't evaluable as an expression. > > 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. This sounds useful. Although I believe something like this should not be difficult to achieve with a Jupyterlab extension. > > 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! I agree Jupyter could be a bit more interactive with syntax errors, for instance, moving the cursor to the point in the input where the error is, instead of just printing the syntax error message. > > 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. SymPy's init_printing() has some flags to make interactive usage more pleasing, such as automatic wrapping of integer literals with sympy.Integer and automatic defining of undefined variables as Symbols. We don't have any options to flip ^ but it could be added. However, our general philosophy with SymPy is that people are better off learning Python syntax, rather than a fake Python syntax that will mislead them when they use a real Python. > > 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. I believe you can get the LaTeX from a MathJax rendering by right clicking on it. Or you can use the SymPy latex() function to get the latex formula from an expression. Having LaTeX itself installed is irrelevant to this. However, I'll note that you can use it with init_printing(use_latex='png'), which makes the outputs use LaTeX instead of MathJax. Aaron Meurer > > 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. -- 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/CAKgW%3D6JyPrbRVdvKj523-cSsgJi6%2BGojYZNdrpSqvkOZHamqWQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
