On Jun 1, 2011, at 9:35 PM, Ronan Lamy wrote:
> Le mercredi 01 juin 2011 à 20:12 -0600, Aaron Meurer a écrit :
>> A few things:
>>
>> - Even if we made isympy play nice, doctests assume just a regular
>> pure Python shell. So any doctest of a function that somehow has a
>> list, tuple, or dict of sympy objects would have to be changed to
>> either use less nice format (srepr()), or to use a printer that gets
>> around it.
>>
> Well, we're already running doctests under our own printer - that's why
> we had to essentially fork doctest from the stdlib. I think bin/doctest
> doesn't actually execute any __repr__() method from sympy objects.
>
>> - If we fix issue 2359, then I'd say about 90% of "typical" SymPy
>> expressions would work with eval(str(x)) == x, assuming that Symbols
>> have been instantiated (both str and srepr require "from sympy import
>> *"). And as we know, sympify(str(x)) == x should *always* work
>> assuming the expression is "generic" enough (i.e., standard functions
>> like sin() or exp() haven't been overridden, Symbols have default
>> assumptions, etc.).
>>
>> srepr() also does things like Add(Symbol('x'), Symbol('y')) instead of
>> Symbol('x') + Symbol('y'), which I guess is more efficient so should
>> probably stay as long as srepr() is the *really* long form of an
>> expression.
>>
>> - I use .args mainly to get at some part of an expression that I don't
>> want to re-type. If this always return the srepr() expression, that
>> would be useless. Granted, I always use isympy, which uses pprint,
>> not str, but I just wanted to point out that .args is not just used
>> for debugging.
>>
>> - But even considering debugging, the srepr() form is, in my opinion,
>> less useful for SymPy expressions than str(). From what I gathered
>> from the discussions I saw on this on the Python mailing list and
>> elsewhere, SymPy is rather unique in the fact that str(expr) <
>> srepr(expr) by quite a bit for all but trivial expressions.
>> Pow(Add(Symbol('x'), Mul(Symbol('x'), Symbol('y')), Pow(Symbol('x'),
>> Integer(2))), Rational(1, 2)) is only more useful than sqrt(x**2 + x*y
>> + x) if you want the eval(repr(x)) == x, which (unfortunately) doesn't
>> really apply in list/tuple/dict's calling of __repr__ with __str__.
>>
>
> OK, srepr(x**2 + x*y + x) is unreadable, but it could be improved by
> indenting and falling back to a more condensed representation beyond a
> certain depth in the expression tree. For instance:
>
> Pow(
> Add(Symbol('x'), Mul(x, y), Pow(x, 2)),
> Rational(1, 2)
> )
But then what's the point? If you are going to have a bare x without Symbol('
') around it why not just stick with the __str__ output, which is easy to read.
By the way, out of curiosity, what exactly are the uses of repr(). When do you
need to be able to eval(repr(x))?
Aaron Meurer
>
>> Aaron Meurer
>>
>> On Sun, May 29, 2011 at 1:07 PM, Ronan Lamy <ronan.l...@gmail.com> wrote:
>>> Le dimanche 29 mai 2011 à 08:25 -0700, Vinzent Steinberg a écrit :
>>>> On 28 Mai, 17:40, Ronan Lamy <ronan.l...@gmail.com> wrote:
>>>>> I don't care about that, because we don't put stuff inside containers
>>>>> that often, because I usually want the repr when I look at .args, and
>>>>> because the only shell I really care about is ipython, which prints this
>>>>> nicely in any case.
>>>>
>>>> I care about pure python shells. However, I could live with it if
>>>> there was a trivial way to setup printing as in isympy (calling
>>>> init_printing() probably already does this).
>>>>
>>> There is:
>>>
>>> ronan@ronan-desktop:~/Projets/sympy-git$ python
>>> Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24)
>>> [GCC 4.5.2] on linux2
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>>>> from sympy import *
>>>>>> import sys
>>>>>> sys.displayhook = pprint
>>>>>> class A(object):
>>> ... def __str__(self): return "A"
>>> ...
>>>>>> A()
>>> A
>>>>>> [A()]
>>> [A]
>>>>>> str([A()])
>>> [<__main__.A object at 0x9d2024c>]
>>>
>>>>> What matters is that:
>>>>> * we can't change it
>>>>> * people new to sympy who know Python expect it
>>>>> * there is a lot of code outside sympy that takes this behaviour for
>>>>> granted and works with/around it.
>>>>
>>>> On the other hand, eval(repr(x)) == x does not hold in general, see
>>>> for example lambda, functions, numpy arrays etc.
>>>
>>> Sure. But what I meant by "this behaviour" is the fact that str() is
>>> supposed to be the nice, human-friendly representation of the object,
>>> while repr() shows what's actually inside the object, and that the str()
>>> of built-in containers isn't actually nice enough for most uses.
>>>
>>> --
>>> 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
>>> sympy+unsubscr...@googlegroups.com.
>>> 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 sympy@googlegroups.com.
>> To unsubscribe from this group, send email to
>> sympy+unsubscr...@googlegroups.com.
>> 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 sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> 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 sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
