Hej Robert,

Your other implementation sounds interesting to. I would really love
to see a lazy way which does work well together with class
inheretance. I don't really know enough of the detailed working of
python/cython to implement what you suggest. Are you willing to write
a patch for this?
If not I will just submit the way I solved it (i.e. by handcoding all
the methods) because that is at least a better working version then
the current implementation (i.e. it does work well together with class
inheretance, it has docstrings, and it also makes the functions
visible for tab completion).

thanks in advance,
Maarten Derickx

ps. I do think every single function which is implemented in the lazy
way should be tested. It was only by chance that I discovered that I
broke the sqrt function because that was one of the couple things
which was tested in the __getattr__ docstring. Also the misspelled
ceil/ciel thing would have been found when adding tests.

On Aug 6, 6:21 am, Robert Bradshaw <[email protected]>
wrote:
> On Wed, Aug 4, 2010 at 5:19 AM, Marco Streng <[email protected]> wrote:
> > Robert Bradshaw schreef:
>
> >> What should be done is either fixing LazyNamedUnop to preserve
> >> documentation, or populating these methods at class creation time
> >> (rather than attribute lookup time, perhaps dynamically creating a
> >> docstring for them). I don't think it's a good idea to hard code every
> >> one of these methods, and the set of methods on RealNumbers will
> >> grow/change over time, and that's a lot of redundant code. If you need
> >> to do one or two (like sqrt) than that makes sense, but probably not a
> >> good idea to do all of them. Verbose code takes resources (both human
> >> and computer) to keep around. At least that's my $0.02.
>
> > Hi Robert,
>
> > Interesting solutions, but I see some problems with them. Possibly because
> > of my own lack of experience, so maybe you can explain.
>
> > I don't understand how "fixing LazyNamedUnop to preserve documentation"
> > helps. If sqrt gets defined in RingElement, then __getattr__ of LazyWrapper
> > doesn't get called. Where does LazyNamedUnops appear in this story?
>
> This is orthogonal to the sqrt issue, I'm just pointing out something
> that's broken.
>
> > Populating sqrt of LazyWrapper at class creation time is interesting. I
> > assume you do that via its __init__ method. But how do you get around the
> > following problems?
>
> Not __init__, at class creation (or perhaps module load) time. I
> haven't looked into the details, this may be harder to do with a cdef
> class but should be easy to do for a Python class.
>
> >  * If a class HypotheticalObject extends LazyWrapper and has its own actual
> > sqrt attribute, then that sqrt attribute gets overwritten at creation time
> > as well, doesn't it? Preventing stuff like this from happening and (even
> > worse) debugging whenever this happens is also a lot of work, isn't it? Is
> > there a way to do what you suggest in a stable and not-too-complicated way?
>
> Not if it's part of the LazyWrapper class, rather than an instance attribute.
>
> >  * The methods created at class creation time must have documentation
> > including examples. This documentation doesn't appear in the reference
> > manual and these examples aren't doctested. How do you get this
> > documentation in the reference manual and how to doctest these examples?
> > Here I don't mean by copying them, because copies can be changed without
> > changing the original.
>
> The reference manual is created via introspection, which would work
> fine for such methods. A couple examples could be doctested in the
> method creator function (if sin works, you don't really need to test
> all the rest of the trig functions). The documentation would probably
> be a sentence about the wrapper followed by the original function's
> documentation. I haven't fleshed out the details, but I think it could
> be done well.
>
> - Robert

-- 
To post to this group, send an email to [email protected]
To unsubscribe from this group, send an email to 
[email protected]
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Reply via email to