On Thu, Jun 19, 2008 at 3:20 PM, Riccardo Gori <[EMAIL PROTECTED]> wrote:
>
> Hello,
> I'm working at fixing issue 888. It is easy to fix but I don't understand why
> in sympy/utilities/lambdify.py I found that lambdastr function does use
> __str__ for expr.
>
> def lambdastr(args, expr):
> """
> Returns a string that can be evaluated to a lambda function.
>
> >>> from sympy import symbols
> >>> x,y,z = symbols('xyz')
> >>> lambdastr(x, x**2)
> 'lambda x: (x**2)'
> >>> lambdastr((x,y,z), [z,y,x])
> 'lambda x,y,z: ([z, y, x])'
> """
> # Transform everything to strings.
> expr = str(expr)
> if isinstance(args, str):
> pass
> elif hasattr(args, "__iter__"):
> args = ",".join(str(a) for a in args)
> else:
> args = str(args)
>
> return "lambda %s: (%s)" % (args, expr)
>
> But in python doc we can read:
>
> (http://docs.python.org/ref/customization.html)
> ################################
> __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.
>
> __str__( self)
> Called by the str() built-in function and by the print statement to
> compute the ``informal'' string representation of an object. This differs
> from __repr__() in that it does not have to be a valid Python expression: a
> more convenient or concise representation may be used instead. The return
> value must be a string object.
> ################################
>
> As I understand __repr__ should be used to have a pythonic valid expression
> and __str__ should be a normal string. But sympy Basic __repr__
> implementation returns unicode text with repr_level_2 so we can't use it in
> eval().
>
> This is also discussed in issue 697.
>
> I suggest to change this behaviour, so we can make lambdify more robust. Is
> someone working at this?
Hi Riccardo,
sorry for a late reply, I am at a PMAA08[1] conference now, so I get
to emails sporadically.
please go ahead and fix the __repr__ and __str__ methods. As you
rightly cited, let's follow the python policy, i.e. __repr__ to be
something evaluable (or at least something that sympify can handle)
and __str__ a normal string. And get rid of set_repr_level()
completely. Let's use
pprint
for nice unicdoe asciiart printing and other methods for other style
of printing.
The only thing I am not sure now -- what should be the difference
between __str__ and __repr__ then? I know we discussed it in the
issues, but I don't think we came to a conclusion. I think the __str__
should return a good looking string, but this behaviour should not
change using some global state (set_repr_level). Then there should be
functions like pprint, or print_tree or print_unicode to do other
kinds of printing. And as to __repr__, I know it should be something
evaluable, but the quesiton is, whether
(sympify(1)/2).__repr__
should return "1/2" or "sympify(1)/2" (or something else). Note, that
in isympy, we use the "pprint" method, so the comfort way of using
sympy will not change by how __repr__ looks like. If you use regular
python shell, you can also easily hook up pprint, e.g.
>>> from sympy import pprint
>>> import sys
>>> sys.displayhook = pprint
>>> from sympy.abc import x
>>> x
x
>>> x**2
2
x
so it seems to me, that __repr__ should really return something that
you can directly evaluate, i.e.
(sympify("1/2").__repr_
should return sympify(1)/2, or Integer(1)/2, or something like that.
Ondrej
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
