alixander

Also, I don't understand the use of images here. Your first one is basically the equivalent of a cliche speech starting with, "The Marriam-Webster dictionary defines passion as..."

Well said

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.

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.

Maybe not my all-time favorite but a recent one that I liked!

A little difference in intent: The idea I had in mind wasn't for someone to particularly do research/collaborate in a field, but just to discover interesting/enlightening papers to read given the urge to learn, in-depth, something new. I thought about attaching a "pre-requisites" fields or "difficulty" field but I wasn't sure if that'd work. The inspiration was just some people posting in my school's Computer Science group that they wanted to start reading research papers, asking where to start. Hopefully in the near future the "Most Favorite" will be a good list to begin with.

That's a great suggestion, thank you!

It's really up to you how often you update. The whole idea isn't to count precise amounts, just input the healthy portions of your meals and over time, hopefully, you'll see patterns of what nutrition your diet is lacking!