Coding standards super() encouraged - #6

Looks great to me... Thanks!

It might also make sense to add (either in the same bullet point or one right next to it) a statement discouraging multiple inheritance unless there's a good reason for it, as we discussed on-list (with a mixin example for "when it's ok"). If you want to add that in this or another pull request, that's fine, or I can try writing one when I get around to it. Just let me know which.

You're right--I thought of putting in something like that, but I wasn't sure where it would fit. But I'll figure something out and add it to this.

Updated with a multiple inheritance example. It's pretty abstract, but I didn't want the example to implement any specific functionality that would distract from the main point of how that mixin works.

The guideline looks great aside from the small suggestion I made inline.

Regarding the example, I definitely like the idea there, but I think it would be better to use MutableCollection instead of DictMixin. We are specifically saying 2.6 compatibility is required, so we should encourage people to make use of the 2.6 collections instead of the older styles. I think the only change you need to make is replace keys with __iter__, and add __len__ and __delitem__ methods, and you can point out that before 2.6 the same thing was done with DictMixin.

If it isn't too much trouble, it would also be good to have the example method be implemented rather than have all the functionality be "..." - I personally tend to get more out of examples that are runnable, even if the functionality is completely trivial (e.g. something that ends up just like a regular dict but prints messages or something).

I'll take out the background information on the C3 algorithm altogether--you're right that it's just distracting. I'll leave in the link which contains much of that same information anyways.

I also agree on changing DictMixin to MutableMapping, though I'm a bit iffy on filling out the rest of the example. The problem is that most of the use cases for using this in a multiple-inheritance context tend to be non-trivial. Your suggestion of having it print messages, for example, can be achieved simply my subclassing dict; no multiple-inheritance necessary. Maybe I'll try to come up with a different example, or even remove the example altogether and suggest "You don't need to use this unless you know you need to use this" though that feels like a bit of a cop-out.

Should I merge this now, then? Or are you still thinking you might want to write a slightly different mixin example?

No, my preference at this point is to not have an example at all. As far as I'm concerned it's ready to merge.