Dynamically determine base classes on instantiation

[Richard Thomas]

class Foo(object):
    def __new__(cls, arg):
        if isinstance(arg, list):
            cls = FooList
        elif isinstance(arg, dict):
            cls = FooDict
        return object.__new__(cls, arg)

class FooList(Foo, list):
    pass

class FooDict(Foo, dict):
    pass

You could even have __new__ make these Foo* classes dynamically when it encounters a new type of argument.

Chard.

On Thursday, 16 August 2012 18:54:12 UTC+2, Thomas Bach  wrote:
> On Thu, Aug 16, 2012 at 05:10:43PM +0200, Hans Mulder wrote:
> 
> > On 16/08/12 14:52:30, Thomas Bach wrote:
> 
> > > 
> 
> > > So, my question (as far as I can see it, please correct me if I am
> 
> > > wrong) is less of the "How do I achieve this?"-kind, but more of the
> 
> > > "What is a clean design for this?"-kind. My intuitive thought was that
> 
> > > the `merge' function should be a part of the object returned from `F'.
> 
> > 
> 
> > The misunderstanding is that you feel F should return an object with
> 
> > a 'merge' method and a varying abse type, while Steven and others
> 
> > think that F should be a function.
> 
> 
> 
> OK, then my design wasn't so bad in the first place. :)
> 
> 
> 
> I made a class `Model' which wraps the actual type and realized
> 
> `merge' and `F' (with a better name, though) as classmethods of
> 
> `Model' in order to tie together the stuff that belongs together. By
> 
> the way, another need I saw for this design was that
> 
> 
> 
> setattr(Model(), 'foo', {'bar': int})
> 
> 
> 
> works, whereas 
> 
> 
> 
> setattr(dict(), 'foo', {'bar': int}) 
> 
> 
> 
> raises an AttributeError (on Python 3.2). Could someone give me the
> 
> buzz word (or even an explanation) on why that is so?
> 
> 
> 
>      Thomas Bach