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
Hey there, I found this nice bug while developing valid8
With enforce 0.3.4,
@runtime_validationclassFoo:
def__init__(self, fun: Callable):
self.fun=funa=Foo(next)
asserta.fun.__name__=='next'# => raises an AssertionError
Indeed a.fun does not hold your callable, but a proxy to it. This could be ok, but that proxy does not act as a transparent decorator. I would recommend using the very nice decorator library, which I use in valid8 and autoclass
The text was updated successfully, but these errors were encountered:
The snippet you provided works at the moment ('dev' branch) if the object is a callable, excluding objects written in C, such ass built-in functions. next is a built-in function, so I am afraid it will not work with it. I am not sure what would be the best approach to such scenarios as it pretty much impossible to extract a signature from a C-defined function. If you have any suggestion what should or could be done, please feel free to share.
Thanks for the explanation. I'm afraid I do not know enough about C-defined function integration in python to be of any help here, but it seems that at least setting the __name__ attribute right on your decorated function is feasible - as it is present also in built-in functions. This should probably be done automatically by wrapt, but if it is not you can easily set this attribute manually before returning the wrapper.
Hey there, I found this nice bug while developing valid8
With enforce 0.3.4,
Indeed
a.fun
does not hold your callable, but a proxy to it. This could be ok, but that proxy does not act as a transparent decorator. I would recommend using the very nice decorator library, which I use in valid8 and autoclassThe text was updated successfully, but these errors were encountered: