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.
