Lazy request and response decode in CallList

[SlavaSkvortsov]

So, I did it in the most optimized way - you'll decode request and response only once and after you can access them as many as you want w/o extra decoding, trough respx.calls or trough pattern.calls. The only problem - it stores decoded Call in mock._Call object - it could be a bit hard for code reading

Fixes #90

[lundberg]

Really nicely implemented!

It got me thinking though....what if we make the stats part of the CallList, maybe even have CallList extend MagicMock if possible and not too hacky?

Then we wouldn't need to pass call_args_list around.

Hey, we could even move the record method to CallList ;-)

In the transport finally statement we then could:

call = self.calls.record(request, response)
if pattern:
    pattern.calls.record(request, response, call=call)  # passing call here for your shared state
    # or
    pattern.calls.add(call)

For backwards compatibility we can change stats to a transport/pattern property, returning self.calls.stats, or self.calls if a MagicMock, and fire a deprecation warning.

Thoughts @SlavaSkvortsov ?

[SlavaSkvortsov]

What about this? MagicMock does some magic with magic methods, so I used the base class to keep .assert_called_once() logic. For me now it looks better and straightforward.

P.S. If everything is fine, could you add one more hacktoberfest-accepted tag, please? :)

[lundberg]

Legit!

[SlavaSkvortsov]

I faced a problem here. In the previous version, I had here stats = mock.stats. It calls stats property and throws a warning. So, for getting the warning you only need to import API :) I tried to find any solution to fix it and finally came up with this crazy solution with metaprogramming. I don't like it, but it works as expected.

We can merge it and delete respx.stats at the next release or we can just remove it now, w/o deprecation warning.

Or, mb, you can come up with a cleaner solution

[lundberg]

I really appreciate the effort, but I'd say skipping the deprecation warning is better than adding the temporary _deprecate_object.

Let's document the deprecation under Call Statistics instead, OK?

[lundberg]

For some reason, we got an other coverage issue in the transport for py 3.9.

[lundberg]

I really appreciate the effort, but I'd say skipping the deprecation warning is better than adding the temporary _deprecate_object.

Let's document the deprecation under Call Statistics instead, OK?

[lundberg]

Let's round this one up, I'd like to see this PR merged before next release.

Rebase and remove the deprecation warning in the property, and we're good to go @SlavaSkvortsov.

Documented deprecation can be added together with other docs changes for the release.

[SlavaSkvortsov]

It is ready to merge :)