4 ms·

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 s

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

cool-RR 8y ago
(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.
- maxmcd 8y ago
  There's this: https://pypi.org/project/rpdb/ 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.html 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.
whitehouse3 8y ago
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.
- cool-RR 8y ago
  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 :)
- abaldwin7302 8y ago
  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.
- djrobstep 8y ago
  I'd suggest ignoring humourless prigs and keeping the profanity.
- eganist 8y ago
  In practical terms, what would that achieve?
  - wang_li 8y ago
    Professionalism.
    - eganist 8y ago
      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.
      - wang_li 8y ago
        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"?
        eganist 8y ago
        > 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.
- xnyan 8y ago
  Strongly disagree. How specifically does profanity affect the authoritativeness of the code? Your comment comes off as out of touch and old fashioned.
petters 8y ago
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).
- masklinn 8y ago
  > 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.
hguhghuff 8y ago
On the contrary I think the author is spot on. I can never be bothered to get the debugger going no matter how easy.
- hobs 8y ago
  So why would installing another debugger be easier?
  - apetresc 8y ago
    But this isn't a debugger. It's just instrumenting a function with some very verbose logs.
    - stefano 8y ago
      But it's harder to install this, import it, and add a decorator than it is to type "breakpoint()".
      - skybrian 8y ago
        That requires an interactive session, for example starting the program yourself from the command line.
      - scbrg 8y ago
        It might be easier than migrating to 3.7, and then typing "breakpoint()"
karmickoala 8y ago
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.
meddlin 8y ago
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.
- acidburnNSA 8y ago
  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/latest/nbextensions/varInspector/README.html https://jupyter-contrib-nbextensions.readthedocs.io/en/lates...
avbor 8y ago
Not only that, but if you're on Python 3.7 you can use breakpoint() without any imports, which is even shorter.
- SEJeff 8y ago
  TIL: Thanks for sharing this!
xienze 8y ago
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.
mattrp 8y ago
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.
treypitt 8y ago
Agree. those two lines become one in 37 via standard "breakpoint" function

cool-RR 8y ago

(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.

maxmcd 8y ago
There's this: https://pypi.org/project/rpdb/ 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.html 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.

whitehouse3 8y ago

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.

cool-RR 8y ago
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 :)
abaldwin7302 8y ago
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.
djrobstep 8y ago
I'd suggest ignoring humourless prigs and keeping the profanity.
eganist 8y ago
In practical terms, what would that achieve?
- wang_li 8y ago
  Professionalism.
  - eganist 8y ago
    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.
    - wang_li 8y ago
      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"?
      - eganist 8y ago
        > 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.
xnyan 8y ago
Strongly disagree. How specifically does profanity affect the authoritativeness of the code? Your comment comes off as out of touch and old fashioned.

petters 8y ago

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).

masklinn 8y ago
> 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.

hguhghuff 8y ago

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

hobs 8y ago
So why would installing another debugger be easier?
- apetresc 8y ago
  But this isn't a debugger. It's just instrumenting a function with some very verbose logs.
  - stefano 8y ago
    But it's harder to install this, import it, and add a decorator than it is to type "breakpoint()".
    - skybrian 8y ago
      That requires an interactive session, for example starting the program yourself from the command line.
    - scbrg 8y ago
      It might be easier than migrating to 3.7, and then typing "breakpoint()"

karmickoala 8y ago

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.

meddlin 8y ago

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.

acidburnNSA 8y ago
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/latest/nbextensions/varInspector/README.html https://jupyter-contrib-nbextensions.readthedocs.io/en/lates...

avbor 8y ago

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

SEJeff 8y ago
TIL: Thanks for sharing this!

xienze 8y ago

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.

mattrp 8y ago

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.

treypitt 8y ago

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