On May 14, 10:02 am, Volker Braun <vbraun.n...@gmail.com> wrote: > I have no opinion on whether or not to do that on each _repr_ call. It > doesn't do anything for me, but I don't see what the point of flooding the > terminal even faster is.
Not all "repr"s end up on a terminal, though. They can end up in exception messages that get caught, processed, and never printed. The coercion/conversion framework might try to convert via a string (repr would be the more appropriate, since that should be the more "machine readable" version). It could try that, catch the exception generated from a failure, and try something else. At least historically, string representations would get used for hashing every now and again. This already causes: sage: G=matrix([[2 for u in range(20)] for v in range(20)]) sage: G.set_immutable() sage: repr(G) "20 x 20 dense matrix over Integer Ring (type 'print G.str()' to see all of the entries)" sage: A=G sage: repr(G) "20 x 20 dense matrix over Integer Ring (type 'print obj.str()' to see all of the entries)" sage: del G sage: repr(A) "20 x 20 dense matrix over Integer Ring (type 'print A.str()' to see all of the entries)" which is a mild violation of G being immutable (but not without precedent. There are plenty of properties of "immutable" objects that can still change). Incidentally, the hash for matrices seems a bit prone to collision: sage: L=[matrix([[2**j for u in range(20)] for v in range(20)]) for j in range(10)] sage: [m.set_immutable() for m in L]; sage: [hash(m) for m in L] [0, 0, 0, 0, 0, 0, 0, 0, 0, 0] > But I do think the functionality to dig for a variable name from an object > is useful, and should be kept. Agreed. The functionality is sometimes useful, mainly for debugging. I think one has to be very cautious to reach for "inspection" tools during *normal* code execution, though, because the information one accesses via these is usually not really *meant* to be available at the place where you retrieve it. You'll usually be violating (implicit) locality and scope assumptions many people will be making when reasoning about your code (if you go digging in the stack and retrieve a "globals" dictionary from an outer frame from you, you're definitely reaching into information that wasn't originally passed to you). -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
