The parameters to __new__ also get passed to __init__, so:

def __init__(self, flubid):
    ...

You need to accept the flubid argument there, even if you don’t use it in __init__

Here is the relevant comment taken from typeobject.c in 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.

*/

The solution that I ended up using is this:

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]

And then you decorate the class with this, not __init__. Although brandizzi provided me with that key piece of information, his example decorator didn’t function as desired.

I found this concept quite subtle, but basically when you’re using decorators in Python, you need to understand that the thing that gets decorated (whether it’s a method or a class) is actually replaced by the decorator itself. So for example when I’d try to access Photograph.instances or Camera.generate_id() (a staticmethod), I couldn’t actually access them because Photograph doesn’t actually refer to the original Photograph class, it refers to the memoized function (from brandizzi’s example).

To get around this, I had to create a decorator class that actually took all the attributes and static methods from the decorated class and exposed them as it’s own. Almost like a subclass, except that the decorator class doesn’t know ahead of time what classes it will be decorating, so it has to copy the attributes over after the fact.

The end result is that any instance of the memoize class becomes an almost transparent wrapper around the actual class that it has decorated, with the exception that attempting to instantiate it (but really calling it) will provide you with cached copies when they’re available.

Was trying to figure this out as well and I put together a solution that combines some tips from other StackOverflow questions (links in the code comments).

If anyone still needs, try this out:

import functools
from collections import OrderedDict

def memoize(f):

    class Memoized:
        def __init__(self, func):
            self._f = func
            self._cache = {}
            # Make the Memoized class masquerade as the object we are memoizing.
            # Preserve class attributes
            functools.update_wrapper(self, func)
            # Preserve static methods
            # From https://stackoverflow.com/questions/11174362
            for k, v in func.__dict__.items():
                self.__dict__[k] = v.__func__ if type(v) is staticmethod else v

        def __call__(self, *args, **kwargs):
            # Generate key
            key = (args)
            if kwargs:
                key += (object())
                for k, v in kwargs.items():
                    key += (hash(k))
                    key += (hash(v))
            key = hash(key)
            if key in self._cache:
                return self._cache[key]
            else:
                self._cache[key] = self._f(*args, **kwargs)
                return self._cache[key]

        def __get__(self, instance, owner):
            """
            From https://stackoverflow.com/questions/30104047/how-can-i-decorate-an-instance-method-with-a-decorator-class
            """
            return functools.partial(self.__call__, instance)

        def __instancecheck__(self, other):
            """Make isinstance() work"""
            return isinstance(other, self._f)

    return Memoized(f)

Then you can use like so:

@memoize
class Test:
    def __init__(self, value):
        self._value = value

    @property
    def value(self):
        return self._value

Uploaded the full thing with documentation to: https://github.com/spoorn/nemoize