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
--
http://mail.python.org/mailman/listinfo/python-list
