Hacker News Reader

Comment by scaryclam | Hacker News Reader

Interesting project, though I'd suggest losing the line about "can't be bothered to set one up right now" regarding a full debugger. (i)pdb is built in and is simple to use. Perhaps focus on what this can add rather than framing the project as something like a lazy alternative (especially when this may actually be harder to set up than throwing in "import pdb; pdb.set_trace()")?

edit: spelling

View on HN

(i)pdb is built in and is simple to use

pdb and its variants (my favorite is PuDB) are generally difficult to use in complex, corporate projects. If you've got a multi-process, multi-thread Python project running on a remote host, you'll need a really full-featured debugger to work with it effectively. I recommend Wing IDE or PyCharm for that.

There's this: https://pypi.org/project/rpdb/ for remote debugging. Celery also ships with its own rdb: http://docs.celeryproject.org/en/v2.3.3/tutorials/debugging....

Certainly not a counter, as I'm less familiar with Wing and Pycharm's debugging features, but both of these have been helpful to me in multi-process, multi-thread python environments.

Not only that, but if you're on Python 3.7 you can use breakpoint() without any imports, which is even shorter.

TIL: Thanks for sharing this!

On the contrary I think the author is spot on. I can never be bothered to get the debugger going no matter how easy.

So why would installing another debugger be easier?

But this isn't a debugger. It's just instrumenting a function with some very verbose logs.

But it's harder to install this, import it, and add a decorator than it is to type "breakpoint()".

That requires an interactive session, for example starting the program yourself from the command line.

It might be easier than migrating to 3.7, and then typing "breakpoint()"

It isn't always that easy. For example, where I work, bringing up a full stack locally involves multiple Python processes (servers) with the frontend accessed via the browser.

Using this tool will work immediately, while using pdb would be a bother (comparatively).

> It isn't always that easy. For example, where I work, bringing up a full stack locally involves multiple Python processes (servers) with the frontend accessed via the browser.

I'd add that discovering where to put the debugger and how to gate it when e.g. the issue needs warmup isn't trivial in large projects. Even if you know where to put the debugger (possibly a quest in and of itself) the exact callsite might get hit tens or hundreds of times before the issue shows itself.

And then, Python doesn't have a reverse / time traveling debugger, so hitting the callsite isn't always sufficient to understand the issue.

In all honesty, I think a more useful way to do this would be defining high-level tooling based on ebpf or dtrace, such that you can printf or snoop from the outside without having to perform any source edition.

And possibly combine that with a method to attach a debugger from the outside to a running program, using either PyDev.Debugger or a signal handler triggering a set_trace as a poor man's PDD.

Sometimes using a debugger isn’t always the best way. Sometimes you want to print out and examine lots of data taken from multiple runs/loop iterations and it’s simply easier to consume that information when it’s sitting in front of you all at once.

Maybe it’s just me but I’ve never been happy with what pdb provides. My primary mode of debugging is to jump into a i python console and go line by line. If it’s django as mentioned above, I have to say I have learned so much about Django through the console that I don’t think I’d be anywhere at this point if I’d used a debugger.

OP may add that (i)pdb must be interactive, which is limiting if you need to debug non-interactive, e.g., a job in a cluster.

Agree. those two lines become one in 37 via standard "breakpoint" function

I'm currently learning Python and a little bit of numerical analysis with jupiter notebooks. I currently don't know what I'm doing. Pysnooper looks like it could drop in nicely to give some much needed help.

See also: the unofficial Jupyter extension variable inspector. It shows current values of variables in your scope integrated in a notebook [1]. Pretty slick!

[1] https://jupyter-contrib-nbextensions.readthedocs.io/en/lates...

I’d also lose the profanity.

> You can use it in your shitty, sprawling enterprise codebase without having to do any setup.

Debugging is a sensitive subject, particularly given how frustrating it can be. There’s a place for vulgarity somewhere, but I’d rather see your README provide authoritative info than crack jokes.

I wrote a lot of shitty, sprawling enterprise code over the years, and I feel there's no shame in admitting that's what it is :)

I appreciated the README as written. I immediately understood what kind of environment the author intended this to be used in. A more formal explanation would have degraded the message. Vulgarity doesn't have to taken as judgemental, it can also be a good way to express empathy. The way I read it, the author's intent was the latter.

In practical terms, what would that achieve?

Professionalism.

One-word quips sound good on paper, but this is an open source project with engineers as the target audience. It's not seeking (at this time) to bring revenue or make sales, so I'd argue that speaking truth to the problem is more likely to drive up adoption.

Citing professionalism isn't a quip, it's shorthand for a code of conduct and long accepted practices of interaction with others.

May I ask how the word "shitty" more truthful than "poorly written" or "complex"?

> May I ask how the word "shitty" more truthful than "poorly written" or "complex"?

Evokes emotions people affected by a situation can sympathize with more effectively, which by virtue of establishing a shared emotional bond over a topic helps the developer convey not just the situation but the frustrations of the situation more effectively than one might expect "poorly written" or "complex" to do alone.

> Citing professionalism isn't a quip, it's shorthand for a code of conduct and long accepted practices of interaction with others.

The code of conduct isn't uniform, so it can't be used effectively as shorthand for such. But at this point we're in the weeds.

Again, no short-term revenue prospects, just a tool OP wants to socialize to make a few lives easier. If you have an objection over verbiage, that's fine, but it's an exhibition of professionalism from yourself to the OP to build a sound defense of your position as to how it would help the engineer to self-censor the description of a tool where the audience by-and-large may not care.

Up to you. My point is the engineer doesn't need to suppress who they are in this specific context, and my point to you is it shouldn't impact your usage of what looks to be an effective short-term debugging tool.

"Any time somebody tells you that you shouldn’t do something because it’s “unprofessional,” you know that they’ve run out of real arguments." -- Joel Spolsky

Or there is a whole suite of behavior and conduct with well thought out reasons that have been comprehensively debated over the years that have been put under the rubric of professionalism and there is zero reason to rehash the same arguments over and over and over ad infinitum.

The same professionalism that generated a shitty, sprawling enterprise codebase?

Strongly disagree. How specifically does profanity affect the authoritativeness of the code?

Your comment comes off as out of touch and old fashioned.

Reply on news.ycombinator.com