Remember state of the local vars beforehand #123
Conversation
|
If I understand correctly, this is only relevant when using At the very least this seems like a bad idea if the code being traced directly uses variables that appeared beforehand, which your example misses because Hypothetically any variable could be relevant, e.g. if the code uses |
|
If we had this code import pysnooper
with pysnooper.snoop():
c = 2 + 2
d = 4this output will be returned: As you can see there is no "d" in the output. This is a bug of both old and new versions - the very last line not printed. |
|
If we use the tracer with decorators the first event we get it is "call" event. This causes the local variables to be empty, so the bug doesn't occur with decorators. |
We can still see the import pysnooper
def foo(a):
pass
a = 100
with pysnooper.snoop(depth=2):
x = foo(a) |
|
Only if you set some depth (which might add any number of unwanted lines to the output), and even then only if you enter a user defined function. It wouldn't work for just |
|
Could you please provide an example with a*2 or max(a), where the old version behaves better? |
import re
import pysnooper
def main():
string = 'hello world'
pattern = re.compile('world')
with pysnooper.snoop(depth=2):
match = pattern.match(string)
if match:
print('success')
main()I haven't tested on your version, but it doesn't show |
|
No, but if you want to have it shown you can modify the code as import re
import pysnooper
def main():
with pysnooper.snoop():
string = 'hello world'
pattern = re.compile('world')
match = pattern.match(string)
if match:
print('success')
main() |
|
What about: import re
import pysnooper
def check(string):
pattern = re.compile('world')
with pysnooper.snoop(depth=2):
match = pattern.match(string)
if match:
print('success')
check('hello world')You can definitely find ways to see the variables, but it takes effort and maybe even a little imagination. Maybe that's not a big deal, maybe it is. |
|
Your example looks good because you have only one local variable and a small function. Whole check function can be just decorated with @pysnooper.Snoop() and the output should be nice enough. Using the with-construction in the code works the best, where a function is so large that the produced output is big. Large functions usually have a lot of local variables and searching among dozens of them is troublesome. In this case a watch functionality is useful to get values of interesting vars, including the global ones. Another use-case of with-constructions are tracing the parts of for-loops: import pysnooper
def main():
a, b, c, d = 1, 2, 3, 4 # ...
c = 0
for i in range(4):
with pysnooper.snoop():
c += i
2 + 2
main()In this case it writes all local variables every time: With the patch: |
|
@alexbers the repeated Unless you've got some other case or example that's more relevant, I'm in favor of rejecting this PR. |
|
I tried to find a good example in this file: https://chromium.googlesource.com/chromiumos/third_party/portage_tool/+/cros/2.1.9/pym/_emerge/depgraph.py. This is a part of the Gentoo linux build system which calculates the dependencies between packages and it has a really complex logic. I failed to find any places where using the with-construction is better then just decorating the whole function. As you can see, the most interesting places to trace are inside the while and for loops. If with-construction inside the loop is a not important use case, that means I misunderstand how the with-construction should be used. The only use-cases I know are when decorating is not possible (e.g. the code is not inside the function) or when the whole function is too complex to decorate (complex functions have many local variables and/or a lot of code in loop constructions). To I think this pull request can be rejected. When I tried to debug big functions with the with-construction I noticed one problem: the interesting code should be indented. On active debugging, during continuous re-indenting, I I figured out that it is more convenient to paste this line, before the interesting code instead of reindenting it: import pysnooper; pysnooper.snoop().__enter__()This traces till the end of the function or till the __exit__ call. But if user forgot to call __exit__(), it will be the memory leak. I came to this idea: what if to add the pysnooper.start() and pysnooper.stop() functions. If the user forget to call stop(), do the stopping automatically on the function end. This makes the debugging just as simple as def f():
# code
import pysnooper; pysnooper.start()
# ... code ... To make it work it is possible to create a Snoop object with custom __del__ method and add it as attribute of current frame, which calls __exit__. Or it is possible to catch return event from the current frame and do the cleaning up. What do you think about it? |
|
I think this PR strayed too far from known use cases. I'll close it until we'll have more feedback from users. Anyway, thanks for your indepth research into this issue. This could be useful in the future. |
Now the local variables state is examined when the first callback fires. This can be too late, when the variables were created earlier, before the call. For example this code:
produces this output
Here we can see functions, classes, modules, and special variables, declared earlier.
The idea of this one-line patch is to remember the local variables state before the first call, in the __enter__ function:
This adds the symmetry with the __exit__ function, because it contains
and also solves the problem: