Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

enforce is not transparent for Callable types - EnforceProxy #58

Open
smarie opened this issue Nov 10, 2017 · 2 comments
Open

enforce is not transparent for Callable types - EnforceProxy #58

smarie opened this issue Nov 10, 2017 · 2 comments

Comments

@smarie
Copy link

smarie commented Nov 10, 2017

Hey there, I found this nice bug while developing valid8

With enforce 0.3.4,

@runtime_validation
class Foo:
    def __init__(self, fun: Callable):
        self.fun = fun

a = Foo(next)
assert a.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

RussBaz added a commit that referenced this issue Nov 18, 2017
@RussBaz
Copy link
Owner

RussBaz commented Nov 18, 2017

Well, I am using wrapt at the moment. I pushed some tests to check this issue,

https://github.com/GrahamDumpleton/wrapt

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.

@smarie
Copy link
Author

smarie commented Dec 4, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants