[AstroPy] Coding Guidelines draft (comments encouraged)

[Erik Bray]

On 07/10/2011 01:39 AM, Erik Tollerud 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

I'm late to this discussion, so forgive me if it's already been 
discussed (I'm still catching up).  But I'm strongly -1 on the 
discouragement of super() use.

First of all, as Mark pointed out, the examples given are confusing. 
The first super() example is showing an incorrect use.  And the text 
afterwards basically reads "You shouldn't use super() because this 
example will break" when in fact the given example *should* break.

If `class C` in the example used super() as well, the example would work 
as expected.  When in doubt about the method resolution order in a 
complex multiple inheritance case one can always call the .mro() on the 
class to check.

In my experience, most examples of super() being bad seem to be due to 
people not using it correctly or consistently.  A better policy would be 
to *require* super() so that when it's needed it's more likely to work. 
  There *are* cases I've seen where super() is not desired, but they're 
the exception.  Otherwise, I would stick to Raymond Hettinger's advice 
in the linked article--he gets it right.

Erik