irmen / Pyro5

Pyro 5 - Python remote objects
https://pyro5.readthedocs.io
MIT License
303 stars 36 forks source link

add the @noexpose decorator (for methods/functions) #49

Closed eudoxos closed 2 years ago

eudoxos commented 3 years ago

Hi, what do you think about this? It allows cleaner code when a whole big class is exposed and only a few methods should not be. The same be achieved by exposing each member individually, of course. Added a test for this as well.

irmen commented 2 years ago

I'm not a fan.

The idea of expose was to make it explicit what methods are remotely accessible, and not accidentally expose things that should remain inaccessible. Turning things around again is almost reverting to a default behavior where methods are exposed unless you're not forgetting to mark them as noexpose. I don't want to introduce this pitfall, hence closing this PR.

That said, I think there is also another way to not have to sprinkle expose on a lot (but not all) of the methods; create a interposer (or delegation if you wish) class that only contains the methods required in the remote interface, expose this class and register it with pyro, and meanwhile delegate all calls to the actual inner class. Or even perhaps inherit from that remote interface class.

eudoxos commented 2 years ago

Hi, I agree with closing this, actually the problem was that I wanted to force some methods to be called locally always, but Pyro makes unexposed methods inaccessible, not running locally. So I will propose another decorator (perhaps) later. Running locally meaning taking self argument either Proxy or the object, indiscriminately (we use this for I/O and currently call the method as Class.method(local_or_proxied_self,other_object) which does not look pretty.