I have been using python for some years now (although I'm no Guru..) and have almost always been able to debug using PDB or a python IDE.
I'm not sure how this helps debugging?
Is it debugging through some type of logging?
I haven't checked out the source code yet, and the site is fairly brief on actual use-cases.
Thanks for any feedback.
Show HN: PyScribe – A Python library to make print debugging more efficient
11–19 of 19 posts
Re: Show HN: PyScribe – A Python library to make print debugging more efficient
#12I have been using python for some years now (although I'm no Guru..) and have almost always been able to debug using PDB or a python IDE. I'm not sure how this helps debugging? Is it debugging through some type of logging? I haven't checked out the source code yet, and the site is fairly brief on actual use-cases. Thanks for any feedback.
I wish I could give you pros and cons, but I've never touched pdb or used a python IDE before myself. In my 3 years of programming, I've only used print statements to debug (for Python programs).
I'll be adding more documentation soon, but perhaps this is a more informative use case: Too often in my Python programs, I'll do something like, print("x is: " + str(x)). That's already too much to keep typing, but sometimes I'll want to know the type, or maybe it's a dictionary and printing without separators makes them blend together (say, in a for loop). In that case, I'll do: print("---------\nx is: " + str(x) + "\n")
The library allows this to be simplified to "ps.d(x)". It's rather opinionated towards my own workflow and what I was too lazy to keep doing. Perhaps I'll try pdb one day and find my library useless.
Re: Show HN: PyScribe – A Python library to make print debugging more efficient
#13I noticed a couple of minor issues and thought I'd post them here rather than making issues on github since the author is reading. First, desugaring doesn't treat the shebang line of a file properly for executable python scripts on Linux. If the first line is, for example, '#!/usr/bin/env python', then the desugared file has three imports at the top of the file and the shebang line after those imports. It would be ni…
Ah, you're right. Totally forgot about that. Thanks for pointing it out!
Re: Show HN: PyScribe – A Python library to make print debugging more efficient
#14This will probably sound very negative, and while I think there's a need for a nice library to help bring to light what happens to data in your code, I don't think the pyscribe way of doing it (using sugar to transcribing a piece of code into one with more logging) is very useful in the long run.
For one, it seems the only type of change you can watch for are changes via assignment for top level variables. For example, any of the mutable built-ins (and I confirmed this by trying to use pyscribe) can't be watched for all changes. For example, mutating the list later with .append() doesn't log anything, nor does changing a value in a dictionary. You also can't watch a particular key in a dictionary, or an attribute in a class (these lead to parse errors when trying to run pyscribe).
Even if you modified the code to support this, you wouldn't be able to control access everywhere that piece of data went. Suppose I had a dict and and some point:
...
d = {'foo': 'bar'}
ps.watch(d)
ThirdPartyLib.do_stuff(d)
In any case, this type of mutation is generally what causes the most bugs. A value changing by assignment doesn't need a run-time logger. These change are in plain sight; just do a search for the variable name in the local body of the function. Mutation that occurs in other contexts (when the object has been renamed, or passed to another function where access is through a different variable name) is the difficult thing to debug, and pyscribe cannot handle that with the current design.
Honestly, I think this is better handled with mocking objects. See how python Mock library does things, and possibly use it yourself (it wouldn't be all that much work to write your own wrapper, but Mock is seriously powerful). Basically watching a variable means wrapping it with a mocked object that defers all reads/writes to the real object, while logging all those changes. Not relying on desugaring also means you can watch what happens to your data when you pass it into third party libraries.
Re: Show HN: PyScribe – A Python library to make print debugging more efficient
#15I have been using python for some years now (although I'm no Guru..) and have almost always been able to debug using PDB or a python IDE. I'm not sure how this helps debugging? Is it debugging through some type of logging? I haven't checked out the source code yet, and the site is fairly brief on actual use-cases. Thanks for any feedback.
I wish I could give you pros and cons, but I've never touched pdb or used a python IDE before myself. In my 3 years of programming, I've only used print statements to debug (for Python programs). I'll be adding more documentation soon, but perhaps this is a more informative use case: Too often in my Python programs, I'll do something like, print("x is: " + str(x)). That's already too much to keep typing, but sometime…
But, it's dead simple to use an IDE. Plus the code you debug within the IDE is the same as the production code.
It allows to use breakpoints, and watch vars.
There are a bunch of free IDEs, what don't you like about using one?
Re: Show HN: PyScribe – A Python library to make print debugging more efficient
#16This will probably sound very negative, and while I think there's a need for a nice library to help bring to light what happens to data in your code, I don't think the pyscribe way of doing it (using sugar to transcribing a piece of code into one with more logging) is very useful in the long run. For one, it seems the only type of change you can watch for are changes via assignment for top level variables. For exampl…
On further digging some more examples of assignments not caught:
ps = pyscribe.Scriber()
x = 0
ps.p(x)
ps.watch(x)
for x in range(4):
pass
# x is now 3
[x for x in range(5)]
# x is now 4Re: Show HN: PyScribe – A Python library to make print debugging more efficient
#17This will probably sound very negative, and while I think there's a need for a nice library to help bring to light what happens to data in your code, I don't think the pyscribe way of doing it (using sugar to transcribing a piece of code into one with more logging) is very useful in the long run. For one, it seems the only type of change you can watch for are changes via assignment for top level variables. For exampl…
Negative or not, I really appreciate the constructive criticism.
In response to your comments on watch: Indeed, right now it only identifies AST nodes of type "asgn". I imagine other mutations like append and others have different types too, I just haven't gotten around to implementing that. My bad for posting this in a pre-release state.
"Even if you modified the code to support this, you wouldn't be able to control access everywhere that piece of data went." I can see two potential solutions: 1. Identifying nodes of type "call" that have a watched variable as an arg, and then adding an if statement to check if it has changed and printing it only if it has. 2. Analyzing AST of ThirdPartyLib.do_stuff(arg1), identify statements that mutate arg1, and logging a change after the call in the original program if arg1 is changed. This way even if the value isn't changed, it's still logged because it was mutated (or at least attempted to), which is probably more desirable than solution 1.
In response to Mock: Aside from Mock, people have told me they prefer the logging library, pdb, IDEs, etc. for debugging. PyScribe isn't meant to be a separate method of debugging, I intended it to supplement my preferred way, which is just using print statements. Might be it's not the most powerful, but its purpose isn't to compete with other methods of debugging.
Re: Show HN: PyScribe – A Python library to make print debugging more efficient
#18This will probably sound very negative, and while I think there's a need for a nice library to help bring to light what happens to data in your code, I don't think the pyscribe way of doing it (using sugar to transcribing a piece of code into one with more logging) is very useful in the long run. For one, it seems the only type of change you can watch for are changes via assignment for top level variables. For exampl…
On further digging some more examples of assignments not caught: ps = pyscribe.Scriber() x = 0 ps.p(x) ps.watch(x) for x in range(4): pass # x is now 3 [x for x in range(5)] # x is now 4
Ah, I'll have to fix that.
Re: Show HN: PyScribe – A Python library to make print debugging more efficient
#19Earlier quoted context omitted.
I wish I could give you pros and cons, but I've never touched pdb or used a python IDE before myself. In my 3 years of programming, I've only used print statements to debug (for Python programs). I'll be adding more documentation soon, but perhaps this is a more informative use case: Too often in my Python programs, I'll do something like, print("x is: " + str(x)). That's already too much to keep typing, but sometime…
But, it's dead simple to use an IDE. Plus the code you debug within the IDE is the same as the production code. It allows to use breakpoints, and watch vars. There are a bunch of free IDEs, what don't you like about using one?
You think you misunderstood; I didn't try it and not like it, I just never tried it. I'm most productive on Vim/Terminal right now. From a quick google search, it doesn't seem like I can use all the Vim commands in an IDE (though I see some articles on using Vim AS an IDE). Have you personally tried both and preferred an IDE over Vim/Terminal?