Hi, 2011/6/21 [email protected] <[email protected]>
> So I suppose the whole printing of physics.quantum must be refactored. > Maybe I'm capable of doing that, but before thinking about it I prefer to > refactor the tests and get the current pull request in as I see it as an > improvement. > > Should I pursue this or you think it's better to scrap the pull request and > start working on the implementation of PhysicsPrettyPrinter? > Do one thing at time. Finish you current work, submit a pull request and we will see how to restructure physics printers later (because this will require improvements to our printing subsystem in general). > > Stefan > > > On 21 June 2011 10:00, Aaron Meurer <[email protected]> wrote: > >> 2011/6/21 Mateusz Paprocki <[email protected]>: >> > Hi, >> > >> > 2011/6/20 [email protected] <[email protected]> >> >> >> >> >> >> 2011/6/20 Mateusz Paprocki <[email protected]> >> >>> >> >>> Hi, >> >>> >> >>> 2011/6/20 [email protected] <[email protected]> >> >>>> >> >>>> Certain tests pass if unicode characters are escaped (like in >> u"\XXXX") >> >>>> but do not pass if the character is written in unicode (like u"ะค"). >> For >> >>>> examples see the tests that fail in the branch quantum_printing. >> >>>> >> >>>> Those test pass if they are run in python, fail in ipython (there is >> a >> >>>> bug in ipython >> >>>> >> http://stackoverflow.com/questions/5860713/ipython-unicode-in-gnome-terminal-linux >> ) >> >>>> and fail in sympy-bot (I don't know why). They pass if the characters >> are >> >>>> escaped. >> >>> >> >>> How did you run those tests in IPython? I tried your branch both in >> >>> Python (2.6.6) and IPython and all run fine. I used this: >> >>> In [1]: from sympy.utilities.runtests import test >> >>> In [2]: test("sympy/physics") >> >>> (...) >> >>> to run tests under IPython. >> >>> >> >> >> >> I used ./bin/test - the tests passed. Then I copied the assert >> statements >> >> (with all the necessary imports and definitions) in both ipython 0.10 >> and >> >> python 2.7. They worked in python but not in ipython (the unicode >> strings >> >> were badly parsed). >> >> >> >> When running them by using test("sympy/physics") they both pass. >> > >> > If this is caused by a bug in IPython, then I wouldn't bother "fixing" >> this >> > in SymPy, which (as you already mentioned) would lead to unreadable >> tests >> > (imagine reading test_pretty.py with \u escape sequences instead of >> Unicode >> > characters), because most likely it will be fixed in 0.11. Can you show >> > which tests fail for you? (it will save us time reproducing your work) >> > >> >> >> >> >> >>>> >> >>>> My questions is not how to write the test that I gave as an example - >> >>>> they will be rewritten with escaped characters. The question is >> should I use >> >>>> unicode characters (that should be supported by the language) even >> when some >> >>>> tools seem to have problems with them? To me it seems a bad idea >> always to >> >>>> escape characters - the tests become unreadable. >> >>> >> >>> Do you experience any problems with tests in sympy.printing.pretty? If >> >>> not then you should follow *exactly* the approach in pretty and you >> should >> >>> be on the safe side. I see that you implemented printers for physics >> module >> >>> outside sympy.printing. What it the rationale for this? >> >> >> >> The printers (actually they are not new printers, just overridden >> methods) >> >> were already implemented when I started working on them. So I can not >> give a >> >> rationale for them being done outside sympy.printing (Actually I have >> no >> >> idea how else those can be done. As I said, it's just overridden >> methods). I >> >> only refactored them so they can be used more easily. >> >> >> >> But there is one tangential question I would like to ask, Mateusz. >> Should >> >> I move all the printing *tests* to sympy.printing. If so, I was >> completely >> >> ignorant of this practice and I apologize. >> > >> > Actually I was unaware that our printing subsystem allows to use printer >> > implementation from non-printer classes. It's reasonable to have physics >> > printers in sympy.physics but it would be also useful to have printing >> > detached from logic. Logic doesn't change that often but different >> people >> > use different notations, so those who dislike the default notation used >> in >> > SymPy may want to easily change this. Currently the only way to change >> the >> > notation is to subclass selected classes from sympy.physics. It would be >> > much easier if, lets say, pretty printer implementation was in one >> class, >> > e.g.: >> > class PhysicsPrettyPrinter(object): >> > def _print_Ket(self, expr): >> > # do actual printing >> > # and so on >> > This way you have to change one class, if you want to alter only pretty >> > printer. If the user would like to alter all printers, then there will >> be >> > four classes to subclass. The problem is that with our printing >> subsystem >> > it's currently not possible to go this direction, because there is no >> easy >> > way to notify PrettyPrinter (in this example) about physics pretty >> printing >> > submodule without modifying PrettyPrinter (adding PhysicsPrettyPrinter >> as a >> > secondary base class to PrettyPrinter). Maybe metaclasses could help >> here >> > (register auxiliary printer classes on first import of a module >> > (sympy.physics in this case)). >> >> +1 to this idea (if it works). I think that this would benefit more >> than just the physics module. Right now our documented method for >> doing this is to override Basic.__str__ (see >> http://docs.sympy.org/dev/modules/printing.html). >> >> Aaron Meurer >> >> > >> >> >> >> >> >>> >> >>> I would create mixin classes for repr, str, pretty and latex with >> >>> appropriate printing methods and add those classes as basses to >> appropriate >> >>> printers. This way, you will have to make sure that Unicode is setup >> >>> properly only in one or two files, not n >> 2. >> >>> I would also use U() function from pretty_symbology.py, to make sure >> that >> >>> Unicode character you use is actually globally available. U() will >> give you >> >>> None if given character (which you will specify by Unicode name) >> belongs to >> >>> the standard or not. It often happens that on a certain platform you >> can get >> >>> more Unicode symbols, but they aren't available elsewhere. >> >>> >> >>>> >> >>>> Regards >> >>>> Stefan >> >>>> >> >>>> P.S. # -*- encoding: utf-8 -*- was present when the tests failed >> >>>> >> >>>> -- >> >>>> You received this message because you are subscribed to the Google >> >>>> Groups "sympy" group. >> >>>> To post to this group, send email to [email protected]. >> >>>> To unsubscribe from this group, send email to >> >>>> [email protected]. >> >>>> For more options, visit this group at >> >>>> http://groups.google.com/group/sympy?hl=en. >> >>> >> >>> Mateusz >> >>> >> >>> -- >> >>> You received this message because you are subscribed to the Google >> Groups >> >>> "sympy" group. >> >>> To post to this group, send email to [email protected]. >> >>> To unsubscribe from this group, send email to >> >>> [email protected]. >> >>> For more options, visit this group at >> >>> http://groups.google.com/group/sympy?hl=en. >> >> >> >> -- >> >> You received this message because you are subscribed to the Google >> Groups >> >> "sympy" group. >> >> To post to this group, send email to [email protected]. >> >> To unsubscribe from this group, send email to >> >> [email protected]. >> >> For more options, visit this group at >> >> http://groups.google.com/group/sympy?hl=en. >> > >> > Mateusz >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "sympy" group. >> > To post to this group, send email to [email protected]. >> > To unsubscribe from this group, send email to >> > [email protected]. >> > For more options, visit this group at >> > http://groups.google.com/group/sympy?hl=en. >> > >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/sympy?hl=en. >> >> > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > Mateusz -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
