Hi koffie, On 31 Jul., 16:57, koffie <[email protected]> wrote: > ... What goes wrong is > that they add functions to a class in sage.rings.real_lazy in a way > that I don't understand and in a way that seems not very compatible > with good object oriented coding conventions.
I had a brief look at the code, and it seems that the LazyWrapper has a custom __getattr__ method, which looks up additional arguments in a list named_unops. If the argument name is known then an instance of the class LazyNamedUnop is returned. When the LazyNamedUnop instance is initialized, the given method name is looked up as a function in "math". So, it seems that sqrt for LazyWrapper is ultimately defined in the module "math", which is (to my understanding) Python builtin. On the positive side, this is easier than adding one attribute for each function in "math". Difficult though it seems to work with such code. > Below you what happens > if you would want to see the source code of the sqrt function of > elements of the Real Lazy Field I agree that this "error opening source code" sucks. The attitude to hide the code (and even the documentation, in some cases!) behind layers of abstraction seems a side-effect of the new category framework (perhaps not in this particular case, I don't know). Since I like to learn from reading code, I find it anti-pedagogical. > Now adding the sqrt function to RingElement (from which LazyWrapper > eventually also derives) breakes the construction by which the sqrt > function is added and now a.sqrt() becomes the function defined for > RingElement. If the sqrt() function of LazyWrapper was added through > normal class extensions there would have been no problem since the > very general sqrt() function would get overwritten and everything > would work as before. Probably you are right: The sqrt method of LazyWrapper is obtained by a __getattr__ method, but that will only be called if there is no class attribute "sqrt". If RingElement has a class method sqrt then LazyWrapper (ultimately inheriting from it) has as well, thus __getattr__ is out of the game, and so the custom sqrt method of LazyWrappper is gone. Your example shows that it is not a theoretical consideration but really happens. That is not nice. > Does anyone with a bit more understanding of > python then me know what is going on in sage.rings.real_lazy and most > importand, is it possible to make the mechanism by which LazyWrapper > adds the sqrt function overwrite an already existing sqrt() function? One could simply define a *proper* sqrt method for the class in question, rather than relying on the __getattr__ game. Cheers, Simon -- 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
