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