On Fri, Jun 27, 2008 at 08:53:07AM +0200, Ondrej Certik wrote: > > On Thu, Jun 26, 2008 at 7:13 PM, Kirill Smelkov > <[EMAIL PROTECTED]> wrote: > > > > On Fri, Jun 20, 2008 at 05:30:29AM -0700, Pearu Peterson wrote: > >> > >> > >> > >> On Jun 20, 11:42 am, "Ondrej Certik" <[EMAIL PROTECTED]> wrote: > >> > >> Also, let's get rid of set_repr_level()? This is quite an important > >> > >> change, so I'd like to hear opinions of others as well. > >> > > >> > > We already had this discussion in the past: > >> > > >> > >http://code.google.com/p/sympy/issues/detail?id=697 > >> > > >> > > And I think repr(x) should be "Symbol('x')", str(x) should be "x" and > >> > > there should be no Basic.set_repr_level. > >> > > >> > Agree. So you mean this, right Kirill? > >> > > >> > >>> repr(x**2/2) > >> > > >> > Mul(Half(1, 2), Pow(Symbol('x'), Integer(2))) > > > > Yes, exactly. > > > >> There is a problem with this representation - it will > >> be implementation dependent (say, one will change > >> the Half to something else like Rational). > > > > I don't think there is a problem that repr is implementation dependent -- > > in fact repr is usually used for debugging and it is more convenient > > that it'll tell us what exactly some symbolic tree is. > > > > So, if repr says there is a Half - I think it is good that we could > > distinguish it from some Rational. > > > >> Another solution to the repr probelm is to return > >> > >> sympify('x**2/2') > >> > >> that will satisfy the basic assumption behind repr: > >> > >> eval(repr(obj)) == obj > >> > >> (assuming that the parser works correctly) and > >> is well readable. > > > > I think we could have > > > > eval(repr(obj)) == obj > > > > with the above approach too. > > > > At present > > > > eval('Half') > > > > produces NameError, but I think this should be fixed. > > This is fixed trivially just by importing Half: > > In [1]: sympify(Half) > --------------------------------------------------------------------------- > NameError Traceback (most recent call last) > > /home/ondra/sympy/<ipython console> in <module>() > > NameError: name 'Half' is not defined > > In [2]: from sympy.core.numbers import Half > > In [3]: sympify(Half) > Out[3]: <class 'sympy.core.numbers.Half'> > > > > > > > > ---- > > > > I'm for: > > > > >>> repr(x**2/2) > > > > Mul(Half(1, 2), Pow(Symbol('x'), Integer(2))) > > The Pearu's proposition has the advantage that it's shorther. However > I think the repr should be in a way that you can copy & paste for > example into our test suite. Neither sympify() nor Mul(Half(1, 2), > Pow(Symbol('x'), Integer(2))) could (I mean of course you can do that, > but it looks ugly). Another option is this: > > >>> repr(x**2/2) > Symbol("x")**2/2 > >>> repr(x**2/2 /x**2) > sympify(1)/2 > >>> repr(x/x) > sympify(1) > >>> repr(sin(x).series(x)) > Symbol("x") - Symbol("x")**3/6 + Symbol("x")**5/120 + O(Symbol("x")**6) > > > And actually, how about using "x" instead of "Symbol("x")" for all > symbols that are loaded by "from sympy.abc import *" ? The repr would > return a very natural expressions in 95% of cases and it could always > (100%) be evaluated by: > > from sympy.abc import * > from sympy import * > eval( repr(something) ) > > Would that be pythonic? If not, we may for example import "x" (maybe > also y and z) by "from sympy import *", so that x, y, z would be just > that and all other symbols by Symbol("a").
I think before we are going to answer what repr output should be, it would be better to remember what repr does in the first place. Ondrej, I think you are forgetting one important thing -- repr is used often for debugging. I quote http://docs.python.org/ref/customization.html#l2h-183 __repr__(self): Called by the repr() built-in function and by string conversions (reverse quotes) to compute the ``official'' string representation of an object. If at all possible, this should look like a valid Python expression that could be used to recreate an object with the same value (given an appropriate environment). If this is not possible, a string of the form "<...some useful description...>" should be returned. The return value must be a string object. If a class defines __repr__() but not __str__(), then __repr__() is also used when an ``informal'' string representation of instances of that class is required. This is typically used for debugging, so it is important that the representation is information-rich and unambiguous. So, say about Symbol('x') -> 'x' -- symbols could be Dummy, Temporary, they could have non-default assumption, etc. When we are looking at repr(e) we want to know it's internal representation -- that's why repr should be verbose, not terse. For all other use-case we have various printers which could be plugged into interactive Python session either in IPython or in pure puthon with the help of sympy.interactive. I'm still for repr to return verbose internal form. What do you think? -- Всего хорошего, Кирилл. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
