In sympy 0.7.2dev the default matrix class is now MutableMatrix not Matrix.
This pull request allows sympyextension to also render this class.
Matrix is an alias of MutableMatrix. Possible candidate for backport to 0.13.1
to match the next sympy release.
In sympy 0.7.2dev the default matrix class is now mutablematrix not m…
change allows sympyextension to also render this class
Would it make more sense for the sympyprinting extension to live as part of SymPy, so it could easily be kept in sync with changes like this?
To explain more: any importable module with a load_ipython_extension function can be used as an extension, so it could live as e.g. sympy.printing. Extension docs are here: http://ipython.org/ipython-doc/stable/config/extensions/index.html#writing-extensions
I think that is a good idea. How should we go about doing this. Will having the extension living both in sympy and ipython for backwards compatibility with sympy 0.7.1 result in issues? i.e. is there any good way to ensure that the most resent version is loaded?
I guess we'd do something like this:
Also, while we're working on it, it would be good to remove the global _loaded flag - we're trying to move away from the idea that there's only one IPython shell in a given process. It could set an attribute on the shell instead, like ip._sympy_extension_loaded.
global _loaded replaced by ip.sympy_printing_loaded
Just tried out removing the global loaded flag. This seems to work. If this is the way we want to go I will prepare a pull request against sympy for this version and see what they think.
I think putting it in sympy makes sense, although maybe others would disagree.
About the loaded flag - on reflection, is there any harm in simply running the loading code again if the user re-runs %load_ext? Alternatively, maybe the 'load only once' logic should be in the extension manager. I'll ask on the dev list for other opinions.
For this extension there seems to be no problem reloading the extension, but it may be different for others. All the
extensions that ship with ipython seems to use the global _loaded flag.
I am +1 on moving the sympy printing extension to sympy. The global flag is only need to prevent adverse affects from reloading the extension. If there isn't a problem we reloading, the flag is not needed.
See #2462 for getting rid of the global flag (but I haven't touched sympyprinting in that).
I'm not sure if you get a GitHub notification from cross referencing a pull request, but as a note for those interested, I've opened sympy/sympy#1556 to move the sympyprinting extension to SymPy.
This was also discussed at #1523.
Just a small update. Sympy now has a printing extension with this problem solved in sympy.interactive.ipythonprinting
thanks to the work of @flacjacket so we don't need to do any thing here for 0.13.1 but we should provide a fallback to the sympy extension in ipython for 0.14
Do you guys want to start a deprecation cycle for the sympy printing extension in 0.13.1? We should have the SymPy 0.7.2 final out this weekend, unless a serious blocker comes up. When would the release date for 0.13.1 be?
Since #2480 is now doing this we can close this one
Pretty print MutableMatrix in IPython
Allows sympyprinting to render the new matrix default matrix class,
Fix found by @jenshnielsen .