Hi Marko,

I just found the time to reply to these.
> I reread the proposal with MockP. I still don't get the details, but if I think I understand the basic idea. You put a placeholder and whenever one of its methods is called (including dunders), you record it and finally assemble an AST and compile a lambda function to be executed at actual call later.
Precisely.


> But that would still fail if you want to have:
> @snapshot(var1=some_func(MockP.arg1, MockP.arg2))
> , right? Or there is a way to record that?

This would still fail. You would record it like this:
@snapshot(var1=thunk(some_func)(MockP.arg1, MockP.arg2))

thunk stores the function for later and produces another MockP object that listens for __call__.

By the way, MockP is the class while P is a virgin instance of MockP. MockP instances are immutable, so any operation on a MockP instance creates a new object or MockP instance.

I’m also beginning to lean towards
@snapshot(var1=...)
@snapshot(var2=...)

I suspect this would deal better with VCS.

This syntax does have a a nice visual alignment. I’m not entirely sure what kind of indentation PEP 8 recommends and editors give, so the point may be moot if the natural indentation also gives the same visual alignment.

Though both should be supported so the best syntax may win.

James Lu


> On Sep 29, 2018, at 3:22 PM, Marko Ristin-Kaufmann <marko.ristin@gmail.com> wrote:
>
> I reread the proposal with MockP. I still don't get the details, but if I think I understand the basic idea. You put a placeholder and whenever one of its methods is called (including dunders), you record it and finally assemble an AST and compile a lambda function to be executed at actual call later.
>
> But that would still fail if you want to have:
> @snapshot(var1=some_func(MockP.arg1, MockP.arg2))
> , right? Or there is a way to record that?