Comment #10 on issue 2865 by pr...@goodok.ru: str(Matrix(...)) should
give "Matrix(...)"
http://code.google.com/p/sympy/issues/detail?id=2865
Well, I suspected that it can be related with "sympify" function.
But let's determine the targets of "sympify" and how it is related
with "str" and "srepr" functions:
sympify.__doc__
"""
Converts an arbitrary expression to a type that can be used inside sympy.
For example, it will convert python ints into instance of sympy.Rational,
floats into instances of sympy.Float, etc. It is also able to coerce
symbolic
expressions which inherit from Basic. This can be useful in cooperation
with SAGE.
"""
So I suppose that "sympify" was invented to intermediate with various
shells and notebooks. Not python shells. To allow transfering data into
the sympy from them. That's why this function do what it do.
And it is not necessary related with "str" method.
"srepr"...
Similarly, srepr(x + 1) could be `Symbol('x') + 1` instead of
`Add(Symbol('x'), Integer(1))`, couldn't it?
Since we have __add__ magic functions that your example can results:
`Symbol('x') + Integer(1)`
without any "Add" string, (but with Integer(1)), it will be evaluated
normally in python shell and construct the object Add as it is desired.
The same with Mul.
But _print_MatrixBase uses the printer to print the contents of the Matrix
and the printer doesn't know the context of what is being printed: it will
return 1/2 as Rational(1, 2) and 1 as Integer(1). What is needed, perhaps
is a way to know if the Rational needs to be printed in long form or
whether coercion can be relied upon to construct the object.
Yes, to solve this problem , it is possible to add the option to every
method which signals that argument of Matrix or other class can (and will)
converted from pythonic int or float by this class creater. And this
options setted in _print_MatrixBase when it calls to print internal content.
I guess that it is something historical confusing with "str" and "srepr".
And I see that "repr" printer has forgotten status about its necessary aims.
And I guess that the aim of "str" replaced with aim of "repr" (Especially
since the "__str__" uses "__repr__" by default in Python).
And that the aim of "repr" ("str") is used often only for explicitly
showing of classes, constructors and tree of them, instead of human
representation or pure possibility of evaluation. In turns, "str" is used
for obtaining evaluatable string (giving all their initial objectives
to "pretty").
So, I think, that we must firstly understand the goals of those functions,
document them, how they must intermediate with python/ipython and other
shells.
May be I'm mistaken, but if I imagine that "str" was aimed for intermediate
with other shells too, then I still don't see why it must produce the
results which will be evaluated obligatory.
--
You received this message because you are subscribed to the Google Groups
"sympy-issues" group.
To post to this group, send email to sympy-issues@googlegroups.com.
To unsubscribe from this group, send email to
sympy-issues+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy-issues?hl=en.
