Sorry for top posting, writing from a cell phone. I think we need to implement all printing ways we mentioned in this thread, probably in the Printer class just like pretty printing or latex. Then we will just call one in Basic.__str__ and another in Basic.__repr__ and remove all other str and repr methods. We can of course discuss which one to call from where, but then we'll be just discussing a change of exactly one line of code. As to other things, I agree with Fredrik. Fredrik, will you come to euroscipy or scipy2008, so that we can fix this together? It be awesome. :) All students here, please apply for sponsorship to scipy2008, so that enthought has some good students to choose from and that we can hack on sympy at Caltech.:) Ondrej
On 6/27/08, Kirill Smelkov <[EMAIL PROTECTED]> wrote: > > On Fri, Jun 27, 2008 at 11:16:18PM +0200, Fredrik Johansson wrote: >> >> On Fri, Jun 27, 2008 at 10:56 PM, Kirill Smelkov >> <[EMAIL PROTECTED]> wrote: >> >> > 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. >> >> Note "given an appropriate environment". The appropriate environment >> is use within SymPy so I think it is actually sufficient if >> sympify(repr(x)) == x holds, sympify taking the role of eval. It is >> fine in my opinion if repr displays rationals as 2/3, etc. >> >> > 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. >> >> Yes, and this is something I have pointed out before. It is very >> problematic that expressions can have "hidden" properties, that don't >> show up in the output of either repr() or str(). My suggested solution >> is to remove assumptions from expressions and get rid of >> Dummy/Temporary/Wild, just having symbols. > > Why woudn't str(expr) serve for this? > > Guys, you are just forcing someone to invent another pairs of methods > for which repr/__repr__ were originally invented for. > > If repr is not that informative there will be some point in time, where > this information would be needed, and one (probably me) will have to > write say debug/__debug__, but why can't we have this sort of output > right from repr? What are cons of this? My point is that there is > str(expr) and also we can always use sympy.interactive and ipython. > > -- > Всего хорошего, Кирилл. > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
