You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While I have not explicitly added support for multipledispatch, it seems to mostly just work at the moment. However, I have noticed that explicitly dispatching (with a variant) to a multipledispatch dispatched function will fall back to dispatching by type:
importvariantsfrommultipledispatchimportdispatchfromitertoolsimportproduct@variants.primary@dispatch(int, int)defadd(x, y):
returnx+y@add.variant('from_lists')@dispatch(list, list)defadd(x, y):
returnlist(map(sum, product(x, y)))
# These parts work OKprint(add(1, 2))
# 3print(add([1, 2], [3, 4]))
# [4, 5, 5, 6]print(add.from_lists([1, 2], [3, 4]))
# [4, 5, 5, 6]# But add.from_lists still dispatches on type!print(add.from_lists(3, 4))
7
I'm pretty sure the reason is that the @dispatch decorator in both cases returns the same object, so calling add.from_lists is the same thing as calling add.__main_form__:
>>>add.__main_form__isadd.from_lists`
True
One way you could imagine solving this is by reversing the order of the decorators, but @dispatch apparently can't wrap a VariantFunction object (and even if it could, I don't think it would preserve all the special methods, e.g. .variant and each of the variants).
Not sure if it's possible to solve this and if it is whether the change has to happen on our side or on the multipledispatch side. On the bright side, the one thing you can do with this is have some versions of add that are automatically dispatchable by type and some that are only accessible from variants, e.g.:
While I have not explicitly added support for
multipledispatch
, it seems to mostly just work at the moment. However, I have noticed that explicitly dispatching (with a variant) to amultipledispatch
dispatched function will fall back to dispatching by type:I'm pretty sure the reason is that the
@dispatch
decorator in both cases returns the same object, so callingadd.from_lists
is the same thing as callingadd.__main_form__
:One way you could imagine solving this is by reversing the order of the decorators, but
@dispatch
apparently can't wrap aVariantFunction
object (and even if it could, I don't think it would preserve all the special methods, e.g..variant
and each of the variants).Not sure if it's possible to solve this and if it is whether the change has to happen on our side or on the
multipledispatch
side. On the bright side, the one thing you can do with this is have some versions ofadd
that are automatically dispatchable by type and some that are only accessible from variants, e.g.:Not sure how useful this is, but it's better than nothing.
CC @mariusvniekerk @llllllllll @mrocklin
The text was updated successfully, but these errors were encountered: