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
@classmethod as outer decorator fails because divide becomes a classmethod, not a VariantFunction, and doesn't have its fancy variant decorator anymore:
----> 7 @divide.variant('round')
8 def divide(cls, x, y):
9 return round(x / y)
AttributeError: 'classmethod' object has no attribute 'variant'
I think there's no obvious way around that. The other way is with primary as the outer decorator:
I think that this one we can get working, it's just a matter of playing with it in the descriptor or something. Alternatively, we can specifically support a classmethod and staticmethod variant for the @primary and @x.variant variants. The disadvantage to both of these is that it's counter-intuitive for the order of decorators to matter like this, so no matter what happens we'll probably get questions.
The text was updated successfully, but these errors were encountered:
That's the source for the undescript helper in the singledispatch descriptor. It doesn't work with py2 staticmethods as when they are resolved through the descriptor protocol, they return a unique instance of a function (in py3 it returns the same instance, iirc).
If these are useful to you, feel free to use them. objtoolz is MIT licensed but I never published it to pypi. I've mostly used it as storage for object trickery.
TL;DR: We should probably support either
@primary
as the outer decorator and/or add a@primary.classmethod
variant.There's two ways this could compose with the staticmethod / classmethod decorator, and they have different failure modes:
@classmethod
as outer decorator fails becausedivide
becomes aclassmethod
, not aVariantFunction
, and doesn't have its fancy variant decorator anymore:I think there's no obvious way around that. The other way is with
primary
as the outer decorator:This one will succeed, but the way it's implemented now I think it's being called incorrectly:
I think that this one we can get working, it's just a matter of playing with it in the descriptor or something. Alternatively, we can specifically support a
classmethod
andstaticmethod
variant for the@primary
and@x.variant
variants. The disadvantage to both of these is that it's counter-intuitive for the order of decorators to matter like this, so no matter what happens we'll probably get questions.The text was updated successfully, but these errors were encountered: