Hi Simon, Reasonable options. For me, "...?" is an *introspection* tool, so it helps me seeing what things look like to sage. Making its output configurable would detract from its use in that sense (now I have to worry about the fact that the particular object I'm viewing might be distorting my view in some way, forcing me to introspect the introspecting infrastructure)
Users can already change "...?" via subclassing if they really want to (by the time they're requesting features like this they are clearly beyond "newbie" and are probably willing to undertake a modicum of programming to achieve their goals), so in my opinion there is no need to further endorse doing so. For your two concrete proposals: > One problem is, however, that SageObject must not have cdef > attributes, because otherwise sage.structure.sequence.Sequence_generic > (which inherits from SageObject and list) can not be defined. > Suggested work-around: Define set_custom_doc and _sage_doc_ not for > SageObject, but for sage.structure.parent.Parent and > sage.structure.element.Element. Does that mean extra slots on Parent and Element? In that case, -1. Sacrificing a whole slot for such a rarely used feature seems like an unacceptable cost to me. On the other hand, if these have a dict already anyway, then there's no such issue. > Other approach: One could have set_custom_doc as a method of > SageObject, but the value is then stored in a dictionary _custom_docs > in sage.misc.sageinspect, so that H.set_custom_doc(d) stores > sage.misc.sageinspect._custom_docs[id(H)]=d. This has problems with garbage collection: Custom docs would never get reclaimed, so this would effectively create a memory leak. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
