Actually, I think it wouldn't be too bad to just print Tuple(...) as (...) always. As you mention, it would be consistant with other things like Integer.
Aaron Meurer On Mon, Jul 4, 2011 at 8:00 AM, Matthew Rocklin <[email protected]> wrote: > What's the standard practice for printing class names? Whats the argument > against always printing Tuples as tuples? >>>> int(2) > 2 >>>> Integer(2) > 2 >>>> tuple((2, 3)) > (2, 3) >>>> Tuple(2,3) > Tuple(2, 3) > > > On Sat, Jul 2, 2011 at 12:36 AM, Aaron Meurer <[email protected]> wrote: >> >> On Fri, Jul 1, 2011 at 11:20 PM, Chris Smith <[email protected]> wrote: >> > >> > >> > On Fri, Jul 1, 2011 at 11:30 PM, Aaron Meurer <[email protected]> >> > wrote: >> >> >> >> When reviewing Tom's code, I noticed he had this doctest: >> >> >> >> >>> hyper((1, ), [], x) >> >> hyper(Tuple(1), Tuple(), x) >> >> >> >> I mentioned that it would be better to have it print as just >> >> "hyper((1,), [], x)" I didn't realize that the printing of "Tuple" >> >> was happening automatically (see >> >> >> >> >> >> https://github.com/ness01/sympy/commit/5fd60e8b2b496c489b174dd7380b7a96d806d3c1#commitcomment-457433). >> >> >> >> Is there a way to make the printer do this automatically, without >> >> changing Tuple.__str__? Perhaps we should special case it so that >> >> Tuple doesn't print as "Tuple" when it is inside of an expression >> >> (i.e., it would automatically be sympified to a Tuple anyway). >> >> >> > I've only worked on the geometry printing and as I recall I had to work >> > on >> > the print methods for those objects. So my first guess is that hyper >> > would >> > have to have its own method. As far as special casing it, I guess you >> > would >> > have to have some sort of flag like 'arg=True' to indicate that the >> > object >> > is inside of something else; and for now, Tuple would be the only thing >> > paying attention to that flag. >> >> Or maybe some kind of as_unsympified flag, which would let it return a >> simpler kind of expression that would not actually be a SymPy type >> unless passed to sympify(). We could refactor classes like Integer to >> use this, and potentially have a printer that always prints >> copy-and-pastable expressions that give SymPy types, but is distinct >> from srepr in that it always gives the simplest form to do so, like >> >> >>> 2*x >> 2*x >> >>> S(2) >> Integer(2) >> >>> x**2 >> x**2 >> >>> Pow(x, Rational(3, 4)) >> x**Rational(3, 4) >> >> (by the way, I'm not saying this should be the default printer, just >> that it could be *a* printer with this change) >> >> Aaron Meurer >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> To post to this group, send email to [email protected]. >> 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. >> > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to [email protected]. > 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. > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. 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.
