better support for metaclass

[randy3k]

It would be interesting to better support metaclasses

Feature request

For example, one may want to create a function whoami which returns different results when running whoami(int) and whoami(str). (PS, I meant literally whoami(int), not whoami(1))

@dispatch(type(str))
def whoami(x):
    print("you are a string")

@dispatch(type(int))
def whoami(x):
    print("you are a int")

It would work if type(str) and type(str) have different types. Unfortunately, they don't, and they are both type.

It could, however, be accomplished by using a different type function. Consider

class DataType(type):
    def __instancecheck__(self, instance):
        return self.t == instance

    def __subclasscheck__(self, subclass):
        return isinstance(subclass, DataType) and self.t == subclass.t


_data_types = {}

def MyType(t):
    if isinstance(t, type) and t is not object:
        if t not in _data_types:
            _data_types[t] = DataType(
                "{}_type".format(t.__name__),
                (type,),
                {"t": t, "__new__": lambda cls: cls.t})
        return _data_types[t]
    else:
        return type(t)

With this new type function, I could determine the type of str and int with a new system.

isinstance(str, MyType(str))
#> True
MyType(str) == MyType(int)
#> False

Finally, it allows me to do what I originally wanted to do

@dispatch(MyType(str))
def whoami(x):
    print("you are a string")

@dispatch(MyType(int))
def whoami(x):
    print("you are a int")

whoami(int)
#> you are a int
whoami(str)
#> you are a string

Changes required in multipledispatch

In the above example, I would need to replace the type of thisline by MyType though.

In all, I am requesting a customizable type function when the dispatcher is created.

[llllllllll]

The point of multipledispatch is to do type level dispatching, dispatching based on elements of the same type seems to fall outside the scope of multipledispatch. Multipledispatch takes advantage of the partial ordering of types in order to do dispatching, your MyType class has no ordering because it only supports direct equality. If you want to do value based dispatching like in your example, I would just store the functions in a dictionary like so:

_functions = {
    str: lambda: print("you are a string"),
    int: lambda: print("you are an int"), 
}

def whoami(value):
    return _functions[value]()

[randy3k]

My example is an overly simplified example. What I am suggesting is to allow different measurement of hierarchical structure by allowing a different "type" function. It is not necessary to be equivalent to element-based dispatch.

[llllllllll]

What is your actual use case then?

[randy3k]

I just found this package a few days ago and I am exploring the flexibility of it. I would imagine there is an absurd metaclass (some form of this absurd metaclass may exist somewhere),

class Meta(type):
    def __instancecheck__(self, instance):
        return True

    def __subclasscheck__(self, subclass):
        return False


class MyClass(metaclass=Meta):
    pass


isinstance(1, MyClass)
#> True

Though 1 is an instance of MyClass, the current implementation does not dispatch because type(1) is not a subclass of MyClass.

@dispatch(MyClass)
def foo(x):
    return x;

After more thinking, I believe we should check directly isinstance(x, MyClass) rather than issubclass(type(x), MyClass).

[llllllllll]

We use type-based dispatching for performance. It allows us to cache the lookups for subclasses. This is a big performance win. As you said, this metaclass is absurd, so we won't go out of our way to support it.

[randy3k]

I guess we should at least add the possibility to allow custom types.

Changing this to

    def arg_types(self, args):
        return tuple([type(arg) for arg in args])

    def __call__(self, *args, **kwargs):
        types = self.arg_types(args)
         ....

will be good enough (for me to subclass Dispatcher) to fix a less absurd metaclass via issubclass(MyType(x), MyClass)

[mrocklin]

Perhaps a more pragmatic example would be @mariusvniekerk 's work here: #69 .

[randy3k]

#69 is great. it replaces type and issubclass with more flexible alternatives. But I argue that we should allow a user supplied Mytype and possibly also Myissubclass.