Steven W. Orr <[EMAIL PROTECTED]> wrote: ... > name = 'C1' > nclass = new.classobj(name,(D1,),globals()) > globals()[name] = nclass
Here, you're creating a VERY anomalous class C1 whose __dict__ is globals(), i.e. the dict of this module object; > name = 'C2' > nclass = new.classobj(name,(D1,),globals()) > globals()[name] = nclass and here you're creating another class with the SAME __dict__; > globals()[name].m1 = m1replace So of course this assignment affects the 'm1' entries in the dict of both classes, since they have the SAME dict object (a la Borg) -- that is, IF they're old-style classes (i.e. if D1 is old-style), since in that case a class's __dict__ is in fact a dict object, plain and simple. However, if D1 is new-style, then C1.__dict__ and C2.__dict__ are in fact instances of <dictproxy> -- each with a copy of the entries that were in globals() when you called new.classobj, but DISTINCT from each other and from globals(), so that further changes in one (or globals) don't affect globals (nor the other). I guess this might be a decent interview question if somebody claims to be a "Python guru": if they can make head or tails out of this mess, boy the *ARE* a Python guru indeed (in fact I'd accord minor guruhood even to somebody who can get a glimmer of understanding of this with ten minutes at a Python interactive prompt or the like, as opposed to needing to understand it "on paper" without the ability to explore:-). Among the several "don't"s to learn from this: don't use old-style classes, don't try to make two classes share the same dictionary, and don't ask about MRO in a question that has nothing to do with MRO (though I admit that was a decent attempt at misdirection, it wouldn't slow down even the minor-guru in any appreciable way:-). Alex -- http://mail.python.org/mailman/listinfo/python-list