[AstroPy] Coding Guidelines draft (comments encouraged)

Erik Tollerud erik.tollerud at gmail.com
Mon Jul 18 07:43:59 EDT 2011


I agree with the view that "multiple inheritance should be avoided
when possible" is a pretty good guideline.  But Chris identifies the
fact that there really is call for separate classes - the use case
Chris identifies seem to generally go by the name of "mixins."
Fortunately, these are exactly the cases where super() is unnecessary
even in __init__; if the classes are unrelated in functionality, you
can freely just do "SuperClass1.__init__self()" and
"SuperClass2.__init__(self)" without worrying that they will interact
some way.

So with this in mind, it's not clear to me what's best to put in the
guidelines (if anything) on the topic.  Perhaps "multiple inheritance
should be avoided, aside from use of mixins",and define mixins as
superclasses that provide extra functionality or support without
overlapping on the other superclasses? Or "multiple inheritance where
superclasses are derived from the same higher superclass should be
avoided" (i.e. no diamond-inheritance structures, trusting that they
won't overlap if they don't have the same supers)?


On Sat, Jul 16, 2011 at 7:12 AM, Chris Beaumont <beaumont at hawaii.edu> wrote:
> Hi Geert,
>
> In my limited experience, the one exception to "avoid multiple inheritance"
> in Python is when the methods and attributes of the two (or more)
> superclasses do not overlap each other.
>
> An example might be an interactive plotting class that supports
> multithreading, so that a time-consuming rendering step doesn't bog down the
> rest of the application. That class might inherit from "BasePlottingClass"
> to gain all of the plotting code, and "MultiThreadedClass" that helps take
> care of setting up, running, and destroying threads. If the two classes are
> completely different, then there is no ambiguity regarding which method
> overrides which class.
>
> I believe examples like this are why Java forbids multiple inheritance, but
> _does_ allow classes to implement multiple "interfaces" (one of which, e.g.,
> is the "Runnable" interface for multi-threaded classes).
>
> cheers,
> Chris
>
> On Fri, Jul 15, 2011 at 12:14 PM, Geert Barentsen <geert at barentsen.be>
> wrote:
>>
>> Hi Erik et al,
>>
>> Many thanks for your efforts on astropy, this seems very worthwile !
>>
>> My suggestion for the coding guidelines would be to urge people not to use
>> multiple inheritance altogether. Your guideline to avoid "super()" does not
>> remove ambiguity in the case where a subclass does -not- override a method
>> that is implemented by 2 or more superclasses (in this case the
>> super-mechanism still works its magic... unless you demand that every
>> subclass in the whole chain overrides -every- method?)
>>
>> I don't think it is ever possible to use multiple inheritance without
>> understanding the somewhat complex details. Simply having code guidelines
>> which say "do not inherit from more than one class at a time" are far less
>> scary than the complex story about super(). I'm happy to change my opinion
>> if someone comes up with a good example where multiple inheritance makes
>> life better :-)  ... when I studied computer science in university the
>> consensus was they are rare!
>>
>> Geert
>>
>>
>>
>> On 10 July 2011 06:39, Erik Tollerud <erik.tollerud at gmail.com> wrote:
>>>
>>> Hello everyone,
>>>
>>> Now that the vision and name for astropy have been ratified, the
>>> Coordinating Committee (Thomas, Perry, and I) have been working on a
>>> draft of coding guidelines/requirements for the astropy package.  The
>>> intent is to use these items to determine if code in affiliated
>>> packages can be merged with the core package (as outlined in the
>>> vision).  I've posted our draft of these guidelines to the wikispaces
>>> page:
>>>
>>> http://astropy.wikispaces.com/Astropy+Coding+Guidelines
>>>
>>> Feel free to ask questions about or comment on any of these items.  We
>>> want to make sure the community is on board with a common set of
>>> guidelines, so we have tried to take into account discussions that
>>> have already occurred on this list in this draft.  Many of these items
>>> have not yet been discussed,  however, so we will certainly adjust
>>> these guidelines (or add new ones) based on your feedback once
>>> consensus is reached on the list.  We do ask, though, that the
>>> comments/discussion be on the mailing list instead of the wiki page,
>>> so that the archive of the mailing list preserves the full discussion.
>>>
>>>
>>> Also, note that the guidelines reference both a documentation and
>>> testing guidelines document.  I have created pages for these documents
>>> as well:
>>>
>>> Documentation:
>>> http://astropy.wikispaces.com/Astropy+Documentation+Guidelines
>>> Testing: http://astropy.wikispaces.com/Astropy+Testing+Guidelines
>>>
>>> These documents are not fleshed-out, as we wish to solicit ideas from
>>> the community here.  I will send additional messages to this mailing
>>> list shortly to begin the discussion these topics, and ask again that
>>> the discussion for each take place in their associated threads.
>>>
>>>
>>> In the near future we (the committee) will also be sending out a
>>> message on determining project hosting and choice of VCS, as well as a
>>> set of priorities to guide development.  Once we  (the community) have
>>> reached consensus on this items, we can begin the actual work in
>>> earnest!
>>>
>>> Thanks in advance for your ideas and comments!
>>>
>>> --
>>> Erik Tollerud
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>>
>
>
>
> --
> ************************************
> Chris Beaumont
> Graduate Student
> Institute for Astronomy
> University of Hawaii at Manoa
> 2680 Woodlawn Drive
> Honolulu, HI 96822
> www.ifa.hawaii.edu/~beaumont
> ************************************
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
>



-- 
Erik Tollerud



More information about the AstroPy mailing list