I hadn't heard of spyder <https://code.google.com/p/spyderlib/> before Vincent mentioned it so I looked into it and it seemed quite impressing.
It runs on all platforms (including Windows), supports both Python 2.7 and 3 and is actively being developed. Spyder is quite modular in that every part of the UI is created as a separate plugin (importable Python module), and while going through the existing plugins codebase <https://bitbucket.org/spyder-ide/spyderlib/src/46ad228e4fad/spyderlib/plugins/?at=default>, I felt that integrating sage console wouldn't be too hard. There's also support for remote ipython kernels, so for people who don't have sage installed (like Windows users), support for interaction with remote sage server (sagecell?) could be added. I also happened upon this sypder issue <https://code.google.com/p/spyderlib/issues/detail?id=851> (created in 2011) which wished for sage console integration but was tagged wontfix as spyder's team felt it was out of their scope. So I guess doing this would make some people happy. Would integrating sage into spyder make sense as a project? On Sunday, February 1, 2015 at 9:10:10 PM UTC+5:30, William wrote: > > On Sun, Feb 1, 2015 at 7:00 AM, Volker Braun <vbrau...@gmail.com > <javascript:>> wrote: > > IMHO that is out of scope for a GSoC project. Maybe somebody with a lot > of > > experience could do it, but a sound MVC framework with robust test > coverage > > is IMHO going to take more effort. Sure, you can slap together a GUI, > but > > that'll just be another me-too notebook that'll soon be as > unmaintainable as > > SageNB. > > +1 > > > Having said that, if you are going to write a proposal that covers > details > > like, say, unlimited undo/redo and testing in a believable way then I'm > sure > > we would pick it up. > > If there were already a good Python (or IPython) Cross Platform Native > GUI (is there?), then a viable project would be to take it and make it > actually useful for Sage too. You should: > > - find all existing "open source Python (or IPython) Cross Platform > Native GUI's": > - what's their current status? > - how widely used are they > - how's the code quality > - etc. > > Such a list would include IDLE [1]. > > Then take the best existing one, and if it **doesn't totally suck**, > make a plan to extend it to make it useful for Sage. > If there is nothing like the above, after 20 years of Python (and 10+? > years of IPython), with millions of users, then you're probably not > going to write something better for Sage="Python+a massively > complicated library" in 2 months. Or, if you could, then you should > do it for millions of Python users first, not just for Sage. > > (Aside: I agree with Nathann's skepticism about this statement: "In > the notebook, it would be a much harder task than in a native GUI." > Good cross platform native GUI's are also very, very hard to write...) > > William > > [1] http://en.wikipedia.org/wiki/IDLE_%28Python%29 > > -- > William Stein > Professor of Mathematics > University of Washington > http://wstein.org > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
