Нека да видим две точки във вашия въпрос.

Използване на memoize

Можете да използвате мемоизация, но трябва да украсите класа, а не метода __init__. Да предположим, че имаме този мемоизатор:

def get_id_tuple(f, args, kwargs, mark=object()):
    """ 
    Some quick'n'dirty way to generate a unique key for an specific call.
    """
    l = [id(f)]
    for arg in args:
        l.append(id(arg))
    l.append(id(mark))
    for k, v in kwargs:
        l.append(k)
        l.append(id(v))
    return tuple(l)

_memoized = {}
def memoize(f):
    """ 
    Some basic memoizer
    """
    def memoized(*args, **kwargs):
        key = get_id_tuple(f, args, kwargs)
        if key not in _memoized:
            _memoized[key] = f(*args, **kwargs)
        return _memoized[key]
    return memoized

Сега просто трябва да украсите класа:

@memoize
class Test(object):
    def __init__(self, somevalue):
        self.somevalue = somevalue

Нека видим тест?

tests = [Test(1), Test(2), Test(3), Test(2), Test(4)]
for test in tests:
    print test.somevalue, id(test)

Резултатът е по-долу. Обърнете внимание, че същите параметри дават същия идентификатор на върнатия обект:

1 3072319660
2 3072319692
3 3072319724
2 3072319692
4 3072319756

Както и да е, бих предпочел да създам функция за генериране на обектите и запаметяването им. Изглежда ми по-чисто, но може да е някакво неуместно раздразнение:

class Test(object):
    def __init__(self, somevalue):
        self.somevalue = somevalue

@memoize
def get_test_from_value(somevalue):
    return Test(somevalue)

Използване на __new__:

Или, разбира се, можете да замените __new__. Преди няколко дни публикувах отговор относно тънкостите и най-добрите практики за замяна на __new__, които могат да бъдат полезни. По принцип казва винаги да предавате *args, **kwargs към вашия __new__ метод.

Аз, например, бих предпочел да запаметя функция, която създава обектите, или дори да напиша специфична функция, която да се погрижи никога да не пресъздава обект към същия параметър. Разбира се обаче, това е предимно мое мнение, а не правило.

Решението, което в крайна сметка използвах, е следното:

class memoize(object):
    def __init__(self, cls):
        self.cls = cls
        self.__dict__.update(cls.__dict__)

        # This bit allows staticmethods to work as you would expect.
        for attr, val in cls.__dict__.items():
            if type(val) is staticmethod:
                self.__dict__[attr] = val.__func__

    def __call__(self, *args):
        key = '//'.join(map(str, args))
        if key not in self.cls.instances:
            self.cls.instances[key] = self.cls(*args)
        return self.cls.instances[key]

И след това украсявате класа с това, а не с __init__. Въпреки че Brandizzi ми предостави тази ключова информация, неговият примерен декоратор не функционираше според желанията.

Намерих тази концепция за доста фина, но по същество, когато използвате декоратори в Python, трябва да разберете, че нещото, което се декорира (независимо дали е метод или клас), всъщност е заменено от декоратора себе си. Така например, когато се опитах да осъществя достъп до Photograph.instances или Camera.generate_id() (статичен метод), всъщност не можах да осъществя достъп до тях, защото Photograph всъщност не се отнася до оригиналния клас Photograph, а до memoized функцията (от примера на Brandizzi).

За да преодолея това, трябваше да създам клас декоратор, който всъщност взе всички атрибути и статични методи от декорирания клас и ги изложи като свои. Почти като подклас, с изключение на това, че класът декоратор не знае предварително какви класове ще декорира, така че трябва да копира атрибутите след факта.

Крайният резултат е, че всеки екземпляр на класа memoize се превръща в почти прозрачна обвивка около действителния клас, който е декорирал, с изключение на това, че опитът да го създадете (но наистина да го извикате) ще ви предостави кеширани копия, когато са налични .

Параметрите на __new__ също се предават на __init__, така че:

def __init__(self, flubid):
    ...

Трябва да приемете аргумента flubid там, дори и да не го използвате в __init__

Ето съответния коментар, взет от typeobject.c в Python2.7.3

/* You may wonder why object.__new__() only complains about arguments
   when object.__init__() is not overridden, and vice versa.

   Consider the use cases:

   1. When neither is overridden, we want to hear complaints about
      excess (i.e., any) arguments, since their presence could
      indicate there's a bug.

   2. When defining an Immutable type, we are likely to override only
      __new__(), since __init__() is called too late to initialize an
      Immutable object.  Since __new__() defines the signature for the
      type, it would be a pain to have to override __init__() just to
      stop it from complaining about excess arguments.

   3. When defining a Mutable type, we are likely to override only
      __init__().  So here the converse reasoning applies: we don't
      want to have to override __new__() just to stop it from
      complaining.

   4. When __init__() is overridden, and the subclass __init__() calls
      object.__init__(), the latter should complain about excess
      arguments; ditto for __new__().

   Use cases 2 and 3 make it unattractive to unconditionally check for
   excess arguments.  The best solution that addresses all four use
   cases is as follows: __init__() complains about excess arguments
   unless __new__() is overridden and __init__() is not overridden
   (IOW, if __init__() is overridden or __new__() is not overridden);
   symmetrically, __new__() complains about excess arguments unless
   __init__() is overridden and __new__() is not overridden
   (IOW, if __new__() is overridden or __init__() is not overridden).

   However, for backwards compatibility, this breaks too much code.
   Therefore, in 2.6, we'll *warn* about excess arguments when both
   methods are overridden; for all other cases we'll use the above
   rules.

*/