Another thing: throughout this file, initialization functions are called directly, rather than with super(). Is there a reason for avoiding super here, or should that be changed?

Thanks @jakevdp. We should apply this to the v1.3.x branch. @mdboom - shall we cherry pick the commit, or resubmit a PR (this is a general question about the maintenance branch I guess...).

Another thing: throughout this file, initialization functions are called directly, rather than with super(). Is there a reason for avoiding super here, or should that be changed?

I think I remember a discussion between @dopplershift and @jdh2358 regarding issues with multiple inheritance (in #1012 I think) and various __init__s not being called when they were designed to be.

👍 from me

@pelson: Yes, this should be backported to 1.3.x, and possibly 1.2.x (haven't yet checked its applicability there). I think merging to master and then cherry-picking the merge to the branches after is fine (rather than resubmitting PRs).

As per super -- yes, with multiple inheritance being used here, it is safer to not use super. And in general, I prefer not to use super on the grounds of explicit being better than implicit, though it doesn't require care to update when moving classes around the heirarchy, but that's a rare occurrence.

As per super -- yes, with multiple inheritance being used here, it is safer to not use super. And in general, I prefer not to use super on the grounds of explicit being better than implicit, though it doesn't require care to update when moving classes around the heirarchy, but that's a rare occurrence.

Also not that the call signature of super has changed in Python 3.3, I think. I'm not sure if this is something 2to3 handles.