On Sun, Aug 1, 2010 at 5:40 PM, koffie <m.derickx.stud...@gmail.com> wrote: > Hej All, > > I started developing for sage not so long ago and I wonder if there > are some good coding practices / conventions for dealing with global > functions and attributes which have the same name and also do the same > thing. An example of such a global function / atribute combination: > > sage: sqrt(3) > sqrt(3) > sage: 3.sqrt() > sqrt(3) > > I came up with this question because during the developing I ran into > two examples showing the relevance of the question. (And the relevance > is also backed by my experience in using sage as an enduser. Global > functions sometimes doing something else as atributes, or the global > funtion working just fine and not having the local function and all > sort of related unexpected or non-intuitive behaviour) > > Example 1: the valuation function. > def valuation(m, p): > if hasattr(m, 'valuation'): > return m.valuation(p) > if is_FractionFieldElement(m): > return valuation(m.numerator()) - valuation(m.denominator()) > if m == 0: > import sage.rings.all > return sage.rings.all.infinity > r = 0 > power = p > while not (m % power): # m % power == 0 > r += 1 > power *= p > return r > > The first point is that It has some implementation specific for > FractionFieldElements in here of which I think this should not be > there (especially since fraction fields have a valuation method). > I already made a small trac ticket for this now needing review: > http://trac.sagemath.org/sage_trac/ticket/9652 > And the second point is that there is code after: > > if hasattr(m, 'valuation'): > return m.valuation(p) > > I think the code after that should be put in the apropriate ring > element class. The second example shows why. > > > Example 2: A similar thing goes wrong with the is_square() method of > which I recently broke a doctest during developement by adding a > is_square() method to RingElement which raises a "NotImplementedError" > in most cases since I expect others to overwrite it. Instead of the > hasattr they do it by the "try: except AtributeError:" construction. > > In arith.py there are about 20 cases in which things like one of the > examples above happen. And also in some cases similar things happen > using isinstance. > If things like that happen that often then there should be a reason > for that right? Is this part of sage design and am I not getting a > convention/coding style or is it for historic reasons?
It's mostly historical. In fact, I think arith.py was the very first file I created when I started writing Sage. -- William > > In both cases I would like to know some best practices for dealing > with the problems involved in the "global functions versus atributes" > story. And maybe there should be a small part discussing this in the > developerguide in the "Design" or "Conventions for Coding in Sage". > > Kind Regards > Maarten Derickx > > -- > 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 > -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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
