Assuming you want to have a separate list in the subclass, not modify the parent class's list (which seems pointless since you could just modify it in place, or put the expected values there to begin with):

class Child(Parent):
    foobar = Parent.foobar + ['world']

Note that this works independently of inheritance, which is probably a good thing.

Any property of Dog will override a property inherited from Cat. You can re-define a value in Cat, but it won't matter because it has already been overridden by the child. For example:

class Cat:
    age = 0  # Cat.age = 0


class Dog(Cat):
    pass  # Dog.age = Cat.age = 0


Dog.age=1  # Dog.age = 1, and Dog.age no longer points to Cat.age
Cat.age=2  # Cat.age = 2

print(Dog.age, Cat.age)  # Dog.age is no longer Cat.age. They are completely different

Contrast that with this:

class Cat:
    age = 0  # Cat.age = 0


class Dog(Cat):
    pass  # Dog.age = Cat.age = 0

Cat.age = 10  # Cat.age = 10

print(Dog.age, Cat.age)  # Dog.age points to Cat.age, so Dog.age resolves to 10

Python's scoping rules for barenames are very simple and straightforward: local namespace first, then (if any) outer functions in which the current one is nested, then globals, finally built-ins. That's all that ever happens when a barename is looked up, and there's no need to memorize or apply any complicated rules (nor is there any need for a Python compiler to enforce more complicated rules).

Any time you want a different lookup, you'll be using a qualified name, not a bare name. Qualified names are vastly more powerful because the lookup can always be delegated to the objects whose attributes can be requested, and those object can implement whatever lookup rules they need. In particular, in an instance method within a class, self.x is the way to ask the self object to look up attribute name 'x' -- and in that lookup it can delegate to classes, including the implementation of the concept of inheritance (and multiple inheritance, method resolution order, and so on).

The body of a class (as opposed to the bodies of the methods defined in a class) executes as part of the class statement, before the class object is created or its name is bound (in particular, before any of the bases have been defined as being bases -- though this latest detail can never matter when referring to barenames, anyway!-).

So, in your example, in class B, barename x is looked up with the universal rules -- is it a name bound locally? If no, is it bound in any outer function in which this scope is nested? If no, is it bound as a global or built-in? If none of the above, using the barename in question of course causes a name-error exception.

Since you want a different lookup sequence than the barename lookup rules universally enforce, then clearly you need to use a qualified name, not a barename; and a moment's reflection will clearly show that the "one obvious choice" for a qualified name to use for your purpose has to be A.x -- since that's where you want it to be looked up (the bases haven't been recorded anywhere yet at that point, after all... it will be the metaclass, normally type, that will do the bases-binding as part of its job when it gets called after the class body is done executing!-).

Some people are so keenly attached to other "magical" rules for the lookup of barenames that they just can't stand this aspect of Python (originally inspired, I believe, by Modula-3, a little known language that's very well considered in theoreticians' circles;-) -- having to write self.x in a method to specify that x must be looked up on self rather than using the universal barename rules, for example, drives such people batty.

Me, I love the simplicity and universality of the barename lookup rules, and I love using qualified names instead of barenames any time I want any other form of lookup... but then, it's not a secret that I'm madly in love with Python (I have my own grumbles -- e.g., global x as a statement always makes my skin crawl, where I'd much rather write global.x, i.e., have global be a built-in name for "the currently executing module"... I do love qualified names!-), is it?-)

You need to call the constructor of the parent classes manually - Here, self.text is initialize in Parent constructor which is never called:

class Child1(Parent):
    def __init__ (self):
        super(Child1, self).__init__ ()
        # or Parent.__init__ (self)
        self.x = 'x'

"after calling the add_header method on the first class instance (a in this case) b also got the header" Because both instances share same variable headers. headers should be instance rather than a class variable

class Base(object):
    __model__ = None
    def __init__(self):
        self.headers = []

    def add_header(self, *args):
        for h in args:
            self.headers.append(h)

    def set_header_values(self):
        for h in self.headers:
            setattr(self, h, getattr(self.__model__, h))


class ChildOne(Base):
    def __init__(self, model):
        super(ChildOne, self).__init__()
        self.__model__ = model


class ChildTwo(Base):
    def __init__(self, model):
        super(ChildTwo, self).__init__()
        self.__model__ = model


class Model(object):
    foo = 'bar'

m = Model()
a = ChildOne(m)
b = ChildTwo(m)
a.add_header('tralala')
print a.headers
print b.headers 

Output

['tralala']

[]

Additional note

Python class and instance variables cause confusions. Consider the following example:

class A:
    l =[] 

class B:
    l =[]

x = A()
y = A()
x.l.append(1)
print 'class A ', A.l, x.l, y.l

x = B()
y = B()
x.l = [1]
print 'class B ', B.l, x.l, y.l

Output

class A  [1] [1] [1]
class B  [] [1] []

Both examples use very similar looking access to data member 'l' however first example modifies the already existing class variable while second example creates a new instance variable.

In your example should you had an assignment self.headers = [...] instead of self.append(...) your output would be different.

Beside, __model__ attribute in your question has nothing to do with the problem.