Ответ 1

Давайте посмотрим два вопроса о вашем вопросе.

Использование memoize

Вы можете использовать memoization, но вы должны украсить класс, а не метод __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

Во всяком случае, я бы предпочел создать функцию для генерации объектов и memoize. Мне кажется, что это чище, но это может быть какое-то неуместное домашнее животное:

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__.

Я, например, предпочел бы memoize функцию, которая создает объекты, или даже написать определенную функцию, которая позаботится о том, чтобы никогда не воссоздавать объект с тем же параметром. Конечно, однако, это в основном мое мнение, а не правило.

Ответ 2

Решение, которое я использовал, следующее:

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__. Хотя брендиззи предоставил мне эту ключевую информацию, его декоратор-декодер не работал по желанию.

Я нашел эту концепцию довольно тонкой, но в основном, когда вы используете декораторы на Python, вам нужно понять, что вещь, которая украшена (будь то метод или класс), фактически заменяется самим декоратором. Например, когда я попытаюсь получить доступ к Photograph.instances или Camera.generate_id() (статический метод), я не смог бы фактически получить к ним доступ, потому что Photograph на самом деле не ссылается на исходный класс Photograph, он ссылается на memoized функция (от примера brandizzi).

Чтобы обойти это, мне пришлось создать класс декоратора, который фактически взял все атрибуты и статические методы из украшенного класса и разоблачил их как свои собственные. Почти как подкласс, за исключением того, что класс декоратора заранее не знает, какие классы он будет украшать, поэтому он должен скопировать атрибуты после факта.

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

Ответ 3

Параметры __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 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.

*/