Improve interface of run to allow arguments about pyfailsafe HOT 5 CLOSED

I see. I guess your suggestion of interface makes sense from a pythonic perspective. I have 2 concerns though if we go with it:

1. if we want to add it as a non-breaking change, the interface will be ambiguous because there will be two ways of calling run(), which may generate confusion.
2. if we want to avoid the above situation, we should replace the current method with your suggestion and release a new version of the library. This will imply updating a fair amount of code and documentation
   What are your thoughts?

from pyfailsafe.

Could you provide an example that illustrates how your proposal would look like?

from pyfailsafe.

From a users' perspective I imagine the previous example could work like this

return await self.failsafe.run(self._request, url) 

and speaking in terms of the implementation, on a very high level, I imagine the run coroutine at

async def run(self, callable, *args, **kwargs):
    callable = partial(callable, *args, **kwargs)

from pyfailsafe.

Technically, there will still be only one way of calling the function, which is passing the callable and then its arguments. It just so happens that if the user wraps the original call, there will be no extra arguments to pass, as the function was already partially applied.

I forgot to mention before but because of this, the proposed change is backwards compatible (the calls already using the lambda: ... should still work).

The fact that the signature contains *args, **kwargs should already signal that they're optional parameters, and belong to the wrapped callable. Considering this is customary in Python, some users were probably already expecting this kind interface.

In any case, this change merits a new version of the library.

As for the examples and documentation, I would only extend them to mention that, in addition to how users were already using the feature, this new version allows passing the parameters explicitly.

It seems that, with this proposal, there will be three possible cases:

1. Functions that already take no parameters, can be used directly --> This doesn't change

async def my_func(): ....
my_failsafe.run(my_func)

2. Functions that take parameters, and these are wrapped (current use case) --> This will still work.

async def my_func(x): ...
my_failsafe.run(lambda: my_func(1))

3. The new interface

async def my_func(x): ...
my_failsafe.run(my_func, 1)

So let's say [2] is what we already have in the docs and examples, I'd mention in the docs that starting from version 0.5.0 (as of this writing), the format in [3] is also accepted.

The idea is to present a slighly simpler interface, without needing the extra-wrapping before calling the function.

from pyfailsafe.

My main concern in this case is having 2 ways of doing the same thing, i.e. calling the callable with parameters. I'd prefer to have a single, well documented one - being it your proposed new interface.

from pyfailsafe.