<div dir="auto">Hi James,<div dir="auto">I agree. Having a snapshot decorator per variable also has the advantage that we can add parameters to the decorator (e.g., snapshots also need "enabled" and "description" argument).</div><div dir="auto"><br></div><div dir="auto">How should we distinguish the two approaches? (I suppose you would also apply them to requests, ensures and invariant decorator, right?) Is there a terminology? Lambda-based conditions might be the name for the conventional approach with @requests(lambda P: ...). What should we term the approach you proposed?</div><div dir="auto"><br></div><div dir="auto">Re naming: @requests(lambda P: P.arg1 < P.arg2) and @requests_that(P.arg1 < P.arg2)?</div></div><br><div class="gmail_quote"><div dir="ltr">Le dim. 30 sept. 2018 à 22:07, James Lu <<a href="mailto:jamtlu@gmail.com">jamtlu@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Marko,<br>
<br>
I just found the time to reply to these.<br>
> 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.<br>
Precisely.<br>
<br>
<br>
> But that would still fail if you want to have:<br>
> @snapshot(var1=some_func(MockP.arg1, MockP.arg2))<br>
> , right? Or there is a way to record that?<br>
<br>
This would still fail. You would record it like this:<br>
@snapshot(var1=thunk(some_func)(MockP.arg1, MockP.arg2))<br>
<br>
thunk stores the function for later and produces another MockP object that listens for __call__.<br>
<br>
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. <br>
<br>
I’m also beginning to lean towards<br>
@snapshot(var1=...)<br>
@snapshot(var2=...)<br>
<br>
I suspect this would deal better with VCS.<br>
<br>
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.<br>
<br>
Though both should be supported so the best syntax may win.<br>
<br>
James Lu<br>
<br>
<br>
> On Sep 29, 2018, at 3:22 PM, Marko Ristin-Kaufmann <<a href="mailto:marko.ristin@gmail.com" target="_blank" rel="noreferrer">marko.ristin@gmail.com</a>> wrote:<br>
> <br>
> 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.<br>
> <br>
> But that would still fail if you want to have:<br>
> @snapshot(var1=some_func(MockP.arg1, MockP.arg2))<br>
> , right? Or there is a way to record that?<br>
</blockquote></div>