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)). > > >> 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.
