Markus D. Herrmann

> For my use case I would have wanted to use the logging feature of retrying anyway and maybe would have wanted other custom debugging access. @pieper did you try...

> No, I didn't see the event hooks. Not sure that would have been exactly on point for my needs without more work though since I wanted to just know...

@ntenenz would you kindly further elaborate on what you are proposing. Are you suggesting to add a parameter to the constructor to pass a higher-order function that can wrap request...

@ntenenz Thanks for the elaboration. > I'd argue separate parameters for each of the above methods is preferable as it would allow for more fine-grained control. Given they're composable, decorators...

> header manipulation (auth, tracing, etc), logging, retry ... the list goes on. Couldn't most of the features in this list already be supported by implementing a class derived from...

> This means the user must be aware of (and is bound to) the underlying implementation details. If you ever wanted to move from requests to some other library, user...

> Honestly, to me this is not at all about functional vs object-oriented programming, but rather, providing flexibility to the user without the need to create derived classes as well...

> If we were to decorate the function call as defined in my sample above, decorators could be composed arbitrarily by placing them in a list and combining them at...

@pieper did you try the `callback` approach? It would not yet solve the problem of setting the min/max retry values, but it should allow you to inject log messages and...

I am not sure whether this would be possible in a backwards compatible manner. We expose the requests API via the constructor of `DICOMwebClient`. I just tested whether `asks.sessions.Session` could...