\begin{sarcasm}
I'm sure glad that python/sage is so easy to read.
\end{sarcasm}
I don't see what is going on, so I am guessing that
you are doing something different.
I was suggesting the use of STRINGS as indexes.
Now it is possible that the same name, i.e. string
would have different meanings in different scopes and
therefore would be an inappropriate index for documentation,
but are we really talking about documentation for local
variables? In lisp, local variables correspond to values, (and may
have implicit types during compilation); only global / static
symbols have properties, function cells, print-names, documentation
strings...
One can argue that all value-containing locations should have all of
this
paraphernalia, but it is expensive. Part of system design is to make
reasonable choices and compromises.
On Sep 17, 5:57 am, Simon King <simon.k...@uni-jena.de> wrote:
> Hi!
>
> In the last few minutes, I hacked something that provides the
> following:
>
> sage: ZZ.set_custom_doc('I like this text better.')
> sage: ZZ?
> Type: IntegerRing_class
> Base Class: <type 'sage.rings.integer_ring.IntegerRing_class'>
> String Form: Integer Ring
> Namespace: Interactive
> File: /mnt/local/king/SAGE/sandbox/sage-4.7.2.alpha2/local/
> lib/python2.6/site-packages/sage/categories/euclidean_domains.py
> Definition: ZZ(self, x, *args, **kwds=0)
> Docstring:
> I like this text better.
>
> Constructor information:
> Definition: ZZ(self)
>
> My patch does not add slots beyond what is done in #11115, it works
> for all parents (sage.structure.parent.Parent) and it works for any
> SageObject with writeable attributes.
>
> However, it does not work for things like symbolic expressions, since
> they do not allow to write attributes:
>
> sage: x.set_custom_doc('x denotes altitude')
>
> ---------------------------------------------------------------------------
> TypeError Traceback (most recent
> call last)
> ...
> TypeError: Setting custom documentation requires attribute access
>
> In particular, it would not provide what the OP requested.
> Question: Shall I open a ticket and post a patch, or is my suggestion
> not good enough for being called "a feature"?
>
> Best regards,
> Simon
--
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
