> That seems awfully complicated. How about (untested):
>
> sage_python = python
> from sympy import *
> python = sage_python
>
> or (even shorter, and still untested):
>
> from sympy import *
> restore('python')
Sure these may work, but in my mind they are temporary hacks.
> The %whatever syntax in the notebook works by calling the function
> "whatever" in the notebook process's current global scope. I actually
> kind of like this design; it means you can easily add new handlers
> (for instance, you could define a function in one notebook cell and
> use it with the % syntax in the next cell).
I understand why that choice was made, but as more and more modes are
added to the sage notebook, you are going to end up with really odd
side effects like this. I think it is unreasonable to expect that
every possible python package that is ever used in Sage avoid all
names that conflict with Sage mode names.
The killer is that for new users something that works perfectly in
python/ipython fails is Sage (from sympy import *). In this case
debugging it was easy (the package was Sympy and Ondrej hangs out
around here). What happens when someone finds this with some odd
package Foo that the Sage community has no connection with?
I think Ondrej's idea of having a
sage.notebook.register_handler(myhandler) call to register a new mode
is a much cleaner idea. You could even make a magic like:
%register myhandler
Cheers,
Brian
> Carl
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
