when using multi-inheritance and super() in __init__(), super() tries to run each constructor once.
For this to work correctly, it is needed to call super() in each constructor, including for Classes directly inherited from object.

The sample below does not execute correctly because threading.Thread constructor does not call super()
(and because Thread inherit from _Verbose, _Verbose should also call super() )

Sample:
from threading import Thread


class Foo(object):
    def __init__(self):
        super(Foo, self).__init__()
        print('Foo constructor')
        self.param1 = 'foo param1'


class Bar(Thread, Foo):
    def __init__(self):
        super(Bar, self).__init__()
        print('Bar constructor')
        self.another_param1 = "bar another_param1"

    def run(self):
        print("Running (%s - %s)" % (self.another_param1, self.param1))


if __name__ == '__main__':
    threads = []
    for i in range(1, 10):
        thread = Bar()
        threads.append(thread)
        thread.start()

    for thread in threads:
        thread.join()


This sample work by simply inverting Thread and Foo :

(...)
class Bar(Foo, Thread):
(...)

The sample is about threading.Thread, but it's also the same for multiprocessing.Process, and maybe for other modules in stdlib.

attached is a proposed path for threading.Tread in 2.7

I've tested the issue and have the same behavior in 2.7 and in 3.3

Can you please provide a diff in unified format? I don't see any super() in Lib/threading.py.

updated diff file, unified format

The patch is liable to break programs which explicitly call base constructors because the constructor will be called more than once.

It also assumes that the __init__() method of all base classes should be called with no arguments (other than self).  That is true in your example, but won't be in general.

That's right.
Lets consider this 'patch' was more for illustrating my example (like:  this kind of modification may work) than to add directly into python core module... (which i'm not capable of)

But I think the problem remains: do you agree that Classes should include a super() call in their __init__ ?
[btw indeed a super() call with kwargs: super(ClassName, self).__init__(**kwargs)]

> But I think the problem remains: do you agree that Classes should include 
> a super() call in their __init__ ?

No, I don't.

I think super() is an attractive nuisance which is difficult to use correctly in an __init__() method, except in the trivial case where you only have one (non-mixin) base class.

See https://fuhm.net/super-harmful/

Adding Raymond, who thinks super is super, to the nosy list.

http://rhettinger.wordpress.com/2011/05/26/super-considered-super/

Raymond, what do you think?

The _Verbose class and verbose arguments for threading classes and functions were removed in issue13550. Thus this is 2.7-only issue now.

Multi-inheritance is tricky to get right, both for the class being extended and the class extending it.  The APIs mentioned here were never designed for multiple inheritance and aren't supposed to support it.

Your use case would probably be better served by using composition rather than inheritance.  Speaking personally, I almost never subclass Thread, instead I make it an attribute of whatever class I'm writing.

I'm going to decline this suggestion.  Antoine is right that this is a can of worms best less closed.  Likewise, Richard pointed out that there is potential to break existing code.

FWIW, the existence of super() does not imply that all existing classes need to rewritten with super calls.   "Cooperative multiple inheritance" implies a certain degree of pre-planning for meaningful cooperation between the classes.  For generic threading that doesn't seem plausible.

Also note that the referenced super-considered-super article shows how to incorporate non-cooperative classes in the chain without requiring that the original class be modified.