71–80 of 175 posts
Earlier quoted context omitted.
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.
In practical terms, what would that achieve?
While I sometimes use one debug tool or another, I have never understood the aversion to print statements reflected in the title. Sometimes, often even, a print statement is just fine, and anything else is overabstracting it. Not saying other options aren't nice to have available, just that there is nothing wrong with using a simple print statement in many situations.
Once you go down the path, it's easy to start adding more and more, and it's easy to forget about them. They sometimes blend in well with patches you generate, since it's just a 'print()' and nothing obvious like 'import pdb; pdb.set_trace()'
They're very visible in diffs then. And even if accidentally committed they're still easy to spot and eliminate later.
For my Django projects the development server is werkzeug [1] and anywhere a break point is needed I'll add 1/0 in the code then hit refresh in the browser which pulls up an interactive debugger [2]. [1] https://django-extensions.readthedocs.io/en/latest/runserver... [2] https://werkzeug.palletsprojects.com/en/0.15.x/debug/#using-...
Some codebases have built-in logging or tracing functionality: you just flick a switch in a module and begin to get ready-made prints from all the interesting parts. But I've found myself never using those: they are not my prints, they do not come from the context I'm in and they don't have a meaning.
Use what you want but please don't underestimate prints.
With this package, it seems like I can just get my debugging via stderr.
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
Earlier quoted context omitted.
In practical terms, what would that achieve?
Professionalism.
I come from the php world now coding in python. There used to be a very nice library from Symfony called VarDumper: https://symfony.com/doc/current/components/var_dumper.html that would just pretty print variables you dumped to the browser in an easy to consume form. Is there anything like this in python?
There is pretty-print [0], which you could dump inside pre tags, or print to stdout. But honestly, depending on the framework, quicker options exist than (basically) printf debugging. [0] https://docs.python.org/3/library/pprint.html#example
Both use gdb semantics which is great if that's what you're used to.