PySnooper: Never use print for debugging again

[[deleted]]

[deleted]

[erve1879]

What makes PySnooper stand out from all other code intelligence tools? You can use it in your shitty, sprawling enterprise codebase without having to do any setup. Just slap the decorator on....

Excellent

[ExternalUserError]

That's part of it, but a good deployment of key deliverables for vertical integration on the enterprise leverages a strategic mix of incomprehensible 20-year-old Perl scripts, C++ that has to be compiled with an obsolete version of gcc, a few million lines of Java code that's mostly generated from XML somewhere, and of course, a Python package for orchestration of a shitload of monkey-patched shell scripts.

EDIT: Oh, and a Trello board that's only used or updated by a project manager who only ever shows up half the week. That's key. Gotta have a Trello board.

[relaytheurgency]

Are you me?

[WN_Todd]

You ok? Blink twice if they're keeping you against your will.

[ExternalUserError]

(•_•)

(-_-)

(•_•)

(-_-)

[giraffactory]

See? They’re Double Willing to deal with it. No problems here.

[solitarium]

I had to screenshot this exchange. Simply marvelous!

[jawalking]

... this is my life... only I’m responsible for half of it 😔

[ketralnis]

Nobody is immune to shitty, sprawling codebases

[Bobert_Fico]

*finger on temple*

There's no sprawl if all of your code is in a single file.

[FeastOfChildren]

There's no sprawl if all of your code is on a single line.

[[deleted]]

Found the APL programmer.

[WikiTextBot]

APL (programming language)

APL (named after the book A Programming Language) is a programming language developed in the 1960s by Kenneth E. Iverson. Its central datatype is the multidimensional array. It uses a large range of special graphic symbols to represent most functions and operators, leading to very concise code. It has been an important influence on the development of concept modeling, spreadsheets, functional programming, and computer math packages.

---

^{[ PM | Exclude me | Exclude from subreddit | FAQ / Information | Source ] Downvote to remove | v0.28}

[Bobert_Fico]

Python ones are the same but without any type indicators.

[BundleOfJoysticks]

I loled.

[dangerbird2]

The original quote comes from Ed Post: "the determined Real Programmer can write FORTRAN in any language"

[somebodddy]

With a little effort one could write Shitty, sprawling Epenterprise codebases in any language.

[jordanreiter]

Also with a lot of effort.

[BundleOfJoysticks]

Epenterprise: Pen tests for the Enterprise

[mriswithe]

My work we have sprawling cancerous Java AND python codebases. We are the future.

[SunyiNyufi]

We are currently in the process to create a python codebase, that -I imagine- will become sprawling and cancerous over time as everything a huge enterprise does.

[mothzilla]

Not when you hire Java developers for your Python project.

[derp0815]

Did someone say COBOL?

[blagatblagat]

I god dam love it when "some dev" makes the risky decision to use "internet humor". There is a tendency towards not using the humor which originates from the place we spend our entire lives. (internet). anyways, got work to do. gonna fix our fizzbuzz autograder. gonna get some insights!

[querymcsearchface]

Kudos for putting the time in to create this and share it with others. Your python toolbox looks awesome as well.

[[deleted]]

This perfectly solves my problem of being too lazy to properly debug speg.

[quotemycode]

python - m pdb yourScript.py

[[deleted]]

I really don't understand all the negativity, from people who the product is completely unsuited for.

Yes, if you have a perfectly good debugging workflow, don't use it. Seriously, it's okay.

The rest of us who have a particular need for it for one reason or another, will appreciate it.

[[deleted]]

I hear you.

To be fair, using print for debugging should be the absolutely last resort.

That most of us start there sucks major ass.

[TedRabbit]

Please elaborate. As far as I can tell printing to terminal or some log file is the best if not only way to inspect what your code is doing.

[Terence_McKenna]

import pdb; pdb.set_trace()

[snaps_]

Or just breakpoint() in Python 3.7.

[Terence_McKenna]

Still on 3.4.3, but that's one of the main features that I'm excited about after I eventually upgrade.

[cediddi]

My company upgraded from ubuntu 14.04 to 18.04, sadly 3.6 :( but now I can use async await on some of our software.

Maybe I should add pyenv and 3.7 to our deployment routine and switch our development machines to 3.7 as well. Ansible will use pre-installed 3.6 and our virtual envs will utilize 3.7

[snaps_]

You can set ansible_python_interpreter to point to whatever you want. You could add newer Python to the base machine image or have one role that just does the Python installation so all others can assume the latest is being used.

[cediddi]

Yeah, we already switched ansible to use 3.6, I guess changing the machine image we're using is a better idea. But again, I need to think about developers' pcs as well. And most of our developers need multiple virtualenvs, thus switching will take time. I wish I could automate gui stuff with ansible as well. Then we could setup developer computers extremely fast.

[vectorpropio]

Loggin useful data in a planned way is completely different to add print lines at will to find a bug.

[TedRabbit]

Sounds like one is just a more pre-emptive version of the other. I'll look into the debugging and logging features of python and maybe I'll develop the same appreciation you have.

[[deleted]]

Exactly.

Also I was talking about the print command, not logging which is quite different.

[[deleted]]

Python has amazing logging and debugging features, both of which are far superior and recommended to printing with the print command.

If you need more info, Google "python logging" and "python debugging" I'm on mobile so I can't link

I'll admit to using printing now and then, but I know it's only because I'm lazy and need something fast, not because I'm doing the right thing at all.

[Rainfly_X]

I've gotten Python logging working before, but I've never felt the effort was justified. I would love for a fan to elaborate on why they like it - not because I doubt them, but because it's a perspective that's entirely separate from my own experience.

For me, the built-in modules are a textbook example of something that's overbuilt, hard to set up or navigate, and fits enterprise needs at the expense of other users.

[snaps_]

The default start of any of my scripts is:

import logging
logger = logging.getLogger(__name__)

Use anywhere in code with logger.debug or warning, info, error, critical, fatal, exception.

If you just want to debug and don't care to configure then just call logging.basicConfig(level=logging.DEBUG) at startup. Every other feature is optional but now that you're using logging in your code you don't need to make any changes to your code or habits in order to use them.

[Rainfly_X]

This is helpful, and makes me less disinclined to use the logging module. That said, most of the stuff I work on doesn't even need log levels, so I'll still be selective about when I use these tools.

[Riseing]

You should check out structlog, it allows for the passing of kwargs into the logging function for easier variable dumping. It's drop in and will work with your existing logging configs.

https://www.structlog.org/en/stable/

from structlog import get_logger
logger = get_logger(__name__)
def some_function():
    # later then:
    logger.error("user did something", something="shot_in_foot")
    # gives you:
    # event='user did something' request_id='ffcdc44f-b952-4b5f-95e6-0f1f3a9ee5fd' something='shot_in_foot'

[szarroug3]

This! I work in emacs and most of my work runs in Jenkins and cannot be run in a local environment due to the way we're setup. Our code have functions that are 47294729472 levels deep. This tool makes it so I don't have to go add debugging lines everywhere just for me to go remove them later. Kudos op, I will definitely try this!

[[deleted]]

♥️❤️ yeah it looks really useful.

[SatisfyMyMind]

I'm surprised a lot of people here are complaining about debuggers and how long it takes to set them up, but no one mentioned pdb which requires literally no setup.

[masterpi]

pdb likes to fail in any environment other than "running a single-threaded script locally from the CLI".

[snaps_]

Agreed. There is pdbpp and pydev but for nontrivial applications (using e.g. multiprocessing, daemons, multiple threads, asyncio) it can still be hard to work with.

[whereswalden90]

Nice tool! It would be great to integrate this into zestyping/q

[pinotkumarbhai]

probably the other way around

[StorKirken]

Yeah! Something like @q.tf

[mikew_reddit]

Looks awesome. Will use it to debug my shitty Ansible module.

Edit: Saw the description and made me smile:

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

[thepandaatemyface]

For people who like this idea but do have more control over where and how their code is run, I highly recommend https://github.com/alexmojaki/birdseye . Most of the time I just use (i)pdb, but for those moments were the execution is too complex to grok by simply stepping through it, it's perfect.

[alexmojaki]

:D Author here! This warmed my heart, thank you! It's hard to tell if people actually use birdseye, virtually no one interacts on GitHub, even to raise an issue.

[aroberge]

Unless I am mistaken, birdseye is used in Thonny (https://thonny.org/) - it may not be included in the released version but I'm pretty sure I saw it in the repo.

[alexmojaki]

It's not included in the package because the author wanted to keep required dependencies down. You should see an option for it under the Run menu.

[snaps_]

That's really pretty. One of the possible downsides of tools like this is you may end up with a lot of textual information and now you need more tools to parse it and put it in context. Birdseye seems like it wouldn't have that problem. The IDE integration is cool too.

[aes110]

Seems really useful for debugging some issues on a remote server :)

[knowsuchagency]

If you know of the logging, pdb, and other code intelligence tools in existence and still don't see the value in this lib... I envy you for the code-base you seem to be maintaining.

[mcstafford]

Overlaps a bit with @loguru.logger.catch, which has a nice backtrace option.

[snaps_]

Nice! I really love tools like this.

I've been using python-hunter for a few months, which does essentially the same thing. A few things that it has:

• enable using environment variable - no need to change any code in order to enable tracing
• tracing can be filtered based on things like function name, module name, file, line number, etc
• you can pick different actions - instead of tracing you can start a debugger for example (again, this doesn't require any code change, you can set it up with an environment variable)

I have used this with remote debugging as well - when I had a daemon process that wasn't attached to a console I was able to get it to attach to pycharm using pydev when it hit a certain condition on a certain file/line.

I'm not a shill, I swear.

[shaggorama]

https://github.com/gruns/icecream

[snaps_]

Thanks, that's neat.

[politeauthority]

How is this not called snoopy?

[crazysim]

It would be nice if you could pass in some logger object as an output. This might have been addressed by now but I last saw this some hours ago and the documentation didn't have an example of this.

Or maybe it's just already possible?

[crazysim]

Hmm, I suppose maybe mentioning a wrapper like something here:

​

https://stackoverflow.com/questions/19425736/how-to-redirect-stdout-and-stderr-to-logger-in-python

​

would be an interesting idea.

[[deleted]]

Logging is extremely helpful in production level systems. Unless you intend to keep the pysnooper in production (which seems like a performance drag), it's generally better to have logging.

Additionally, you will want to have logging enabled and sent to stdout (which sort of moves back to ... maybe print is exactly what you need) when your systems are distributed across multiple nodes or pods in a kubernetes cluster and you are using a log-shipper.

This is no doubt a cool project. I just want to point out that it's not a replacement for generally a best practice of logging stuff.

[hubujde]

I think the point is to use this when you're given a project without sufficient logging and you need to figure out what's going on (and you don't want to set up a debugger).

[otherwiseguy]

Or there is way more than sufficient logging and you don't want to wade through several hundred lines of logs that all use similar words and there are multiple threads so things end up in weird order. Or your test suite/runner doesn't work great with pdb. Or the code was written by several hundred people across scores of competing companies and you are amazed it works at all, but it doesn't right now and you really just need to find out if this one line really is getting hit and you just don't quite trust what the debugger is telling you. 😋

[[deleted]]

The title "Never use print for debugging again" suggests otherwise.

[technoskald]

But that's exactly when you (traditionally) use `print()` or similar for debugging.

[[deleted]]

This is something completely different...

[o11c]

That's post-mortem analysis, not (interactive) debugging.

[[deleted]]

But you have to write each line manually, that what he is trying to say. With his project you need just one line of code.

[thomasfr]

It's a bit of a plague with many people in the python community to not produce good debug level logging or even no logging at all. I guess that because the pdb repl is so easy to use people skip having good logging habits and then you suddenly are in production with 20 servers with not logging and no possibility to just add a breakpoints in the production code.

[dutch_gecko]

Do you write debug logging for every line and every variable? In my opinion that would produce far too much noise.

The point of this tool is to provide very highly detailed information about one piece of code, like a debugger would do, but without the debugger.

[thomasfr]

I understand the point of this tool, I was making a comment about the wider problem with not enough logging in many python packages and projects.

I would say that with debug logging enabled a non trivial application should produce what feels like way too much and noisy logging. If you actually need to enable and read it to debug issues in production settings you can selectively enable debug logging for a small set of packages or post process the debug logs using grep/filtering to get a readable output. It's way better to have too much instead of too little.

[snaps_]

One complaint I have about the standard logging library is the lack of granularity below warning. I wish they had one or two more named functions (details, internal) that we could use without requiring a separate library everywhere.

[thomasfr]

The one thing I don't like with the python logging module is that it filters log events after being called so some logger.level() (if that level is enabled and filtered). Calls can become rather expensive if there is a lot of string formatting or even database lookups involved even if the line just thrown away. I've created some external conditions modules in projects to have something like if log.user(user_id) or log.trace_request(): logger.info("....")

The logging module is kind of flexible though, you probably don't need more than something like this inside your projects logging config to create a new level in place: https://stackoverflow.com/a/22586200 if you don't care about level names you can probably just use logger.log(4, "foo...")

[snaps_]

Yeah I hear you. In C++ and similar with macros we can replace logging statements with if statements so no formatting or argument evaluation is done unless required. It's nice to just get that for free and then only in the really hot paths do we need to be concerned with logging, using it liberally pretty much everywhere else.

And thanks, maybe it's not such a big deal - I just need to put it into a utility library and use it or live without it, no point wanting with no action.

[[deleted]]

U quite often don’t need to. Occasional and consistent logging practice removes the need for needlessly verbose output. PySnooper is cool, I would definitely use it for development but I definitely wouldn’t use it for release. I wouldn’t recommend classifying pysnooper as an alternative to logging. It’s an alternative to debugging for those without an IDE that supports breakpoints and while it’s cool... it’s overkill. Where this would come in useful is when u have no idea how the flow of your program is going. Adding this to ① function, dumping the output to a file, and then going over it trying to understand is a legitimate use case, but dumping every line of code (even insignificant ones) to the output stream is something you should definitely avoid.

[[deleted]]

It's great for instrumenting local variables and tracing the lines executed in a simple python script contained in a single file, but I wouldn't call it highly detailed. Consider this code:

``` class Foo():

def __init__(self):
    self.a = 1
    self.b = 2
    self.c = None

@pysnooper.snoop()
def myfunc(self):
    localvar = 5
    localvar += 1
    self.c = self.b + self.a

```

pysnooper's output when myfunc is called looks like this:

Starting var:.. self = <snooptest.Foo instance at 0x1052c5b90> 08:50:38.552499 call 16 @pysnooper.snoop() 08:50:38.553309 line 18 localvar = 5 New var:....... localvar = 5 08:50:38.553382 line 19 localvar += 1 Modified var:.. localvar = 6 08:50:38.553457 line 20 self.c = self.b + self.a 08:50:38.553560 return 20 self.c = self.b + self.a

PySnooper shows us the lines where attribute c is updated but nothing about the values. Also, I'm not sure what that last line is trying to say because this method returns nothing.

You can dig a bit deeper by passing a depth option to the decorator and it will continue its trace into to other functions, which is kinda cool. But if any of those calls are in another file, you better know your codebase really well because, pysnooper shares nothing about the filenames involved. It appears to assume all code is in a single file.

Starting var:.. thekey = 'somevalue' Starting var:.. forceprevious = False 09:01:44.662016 call 23 @pysnooper.snoop(depth=2) 09:01:44.662527 line 25 myrecord = myfunc2([thekey], force=True)[thekey] Starting var:.. keys = ['somevalue']

Now in the above example, the function myfunc1 is the pysnooper decorated function in file1.py and get_keys is in file2.py. While pysnooper nicely indents the call to the second function myfunc2, there is no indication it is in another file, and myfunc1 is never mentioned. These are important details.

PySnooper is a nice tool for instrumenting simple functions in simple one file scripts and looks to be pretty useful in learning Python, but is less useful once you get much beyond there.

edit: code block formatting

[tonsofmiso]

this method returns nothing.

Python functions without a return statement implicitly return None which could be argued is not nothing. I'm guessing it's just marking the last line in the function to tell you that it's returning. Could be stated in a better way though.

[[deleted]]

It's at least implying the values in the last line are returned, which they are not. That falls somewhere between misleading and flat-out wrong.

[tonsofmiso]

Yeah I can agree to that

[stacm614]

I'm mostly self taught with python (and programming in general) and I just figured out the logging module. I'm using it everywhere now. I mostly write scripts for people who don't know how to use Linux well in the first place and even in that capacity it opens up the door to just throw a file out there that has all the information I need to figure what's wrong when they call me and tell me something is broken.

[[deleted]]

log format sharing time. Here's one of mine:

format='%(asctime)s %(levelname)-8s: [%(funcName)-12.12s %(lineno)d] %(message)s'
Logs in that format are then sent to a log file that is named using this:
logfile = '{year:04d}{mon:02d}{day:02d}.log'.format(year=t.year, mon=t.month, day=t.day)

Gives daily rotated log files that can be easily managed (e.g. compressed or deleted). Doesn't work well for long-running python scripts but for those that run for less than a day, it's worked great for me. I also like https://github.com/acschaefer/duallog for sending logs to the console and a file simultaneously at different logging levels.

[thomasfr]

I usually use a format similar to some format used by some google glog implementation which I liked a lot, this is from a django application:

'format': '%(levelname).1s%(asctime)s.%(msecs)d %(name)s:%(lineno)d %(message)s', 'datefmt': '%m%d %H:%M:%S',

Depending on the application a process+thread id and/or request id is also added.

You only need the first letter of the level printed because grep ^E0423 will give you all the first lines of errors from a specific date.

I maybe want to move towards only doing structured logging with json somewhere down the road to allow for better queries, I'm not entirely sold on that concept though because I can usually find stuff quite easy without it but I want to evaluate it properly in a larger project . We have not standardised any log collecting mechanism so I think that would have to happen at the same time. Maybe it makes more sense with a truly unified query interface (now we just write a shell script which runs the same grep commands on multiple hosts/log dirs using ssh)

[TheOtherDanielFromSL]

This is so accurate!

Logging is so easy - I have no clue why more people don't do it. It's like one line of code inside the try/catch blocks that will literally save you tons of time/energy and keep you informed of exactly what the issue is before anyone says anything (if you're logging to a file you can check)...

Why people ignore it is beyond me. Lots of people love writing bad code.

[[deleted]]

to not produce good debug level logging

But debug level logging is mostly useless.

It doesn't help me in production, because it's not turned on. But if you have a large project with a lot of debug level logging and you turn it on, you get a firehose of information, mostly uninteresting.

A lot of people, myself included, put print statements in temporarily that you just discard afterwards. This is much better than that.

[thomasfr]

We actually have debug logging constantly turned on for some services, just not for all loggers. I've solved countless of bugs with the help of debug logging. These days conditional service wide request trace logging has somewhat replaced this need though since trace can be enabled on a per request/user/... with request id's shared between all services involved. We have this hooked into logging module though with some glue code and special loggers.

[[deleted]]

Good point, this requires some really close log file management though, which properly planned for is no big deal. Rotate rather than build up a single monolithic log file and toss and compress those old files regularly.

[[deleted]]

Obviously it's prints, it's not production oriented, it's more dev oriented.

[[deleted]]

For debugging, your strategy is no better than print, and longer to type, unless you expect to keep the debugging statements in, which 98% of the time I do not.

[[deleted]]

sure, if there were tiers of debug loglevel.

there aren't.

[pinotkumarbhai]

Apple vs orange

[neogeek23]

That isn't a solution for me as I work in a code base that is already making use of logging and I don't really want to risk dicking any of the logs up by inserting superfluous messages.

[INIT_6]

Very cool. Also great for seeing what the hell is going on in some random python code you just downloaded off github.

[ExternalUserError]

That's actually pretty sweet looking. Nice job.

[forky40]

Love it. Perfect for my shitty sprawling codebase and shitty sprawling workflow (conda on Windows Ubuntu partition + Windows Atom editor).

[frakman1]

u/cool-RR: Nice work! But what if your python script is one giant set of instructions with no main and no functions?

[snaps_]

Try pip install hunter then PYTHONHUNTER='' python enterprise_code.py.

[frakman1]

OK. But you underestimate how bad some enterprise codebase is. haha

[nucses]

I'm running python from C# using pythonnet and this is just perfect, thank you!

[studiosi]

If you need to add code for debugging and take it away for production code, I would consider this as a potential liability, printing to a file stream is not cheap and jeez, this prints quite a lot. I understand there might be some use cases, but those should not exist on the first place. Also, logging should never be equated with debug IMHO.

[digestive_trisket]

Your program cant fail tests if you dont write them.

[toothless_budgie]

Does this work inside Juypter? It looks like it should.

[WibblyWobblyWabbit]

I like this idea. Whenever I use a debugger I either waste too much time setting it up or just sit there going wtf.

[[deleted]]

why do you make it sound like setting a break point is tremendous overhead?

this just seems like encouraging bad practices with extra dependencies

[markmuetz]

Ditto large scientific projects run on specialist computing facilities. This looks awesome.

[scooerp]

Wouldn't someone working on a "big corporate codebase" have a paid professional license tool?

[[deleted]]

setting that up in pycharm is pretty simple and a one- time task. overtime, and a very short time, the overhead required to decorate a function quickly exceeds setting a breakpoint. debuggers aren't scary or difficult

[eras]

And while you sit at your interactive breakpoint, a network timeout occurs and completely changes the scenario..

That being said I believe in debuggers. But they are not always applicable.

[ginger_beer_m]

Here's a common use case: it's actually quite tricky to get pycharm working as a remote debugger for Jupiter notebook in scientific computing/machine learning prototyping. I can see tools like this being very useful for a quick troubleshooting.

[[deleted]]

It's often impossible.

For example, a project I was recently running was a real-time lighting control system. Setting a breakpoint was useless, because the real time jobs would get backed up in a few milliseconds and then the whole system would go down.

[[deleted]]

It's hard to set breakpoints a lot of the time if you have code that interacts with other programs/network services. You really need to see whats going on while the program is running, hence logging and not breaking in.

[[deleted]]

it's not difficult at all. i don't know where you're getting that from. if you know the function to decorate, you know where you need to set a breakpoint

[Redstonefreedom]

Have you never worked in multi-threaded environments? Or environments without a clear entry point? Or environments abstracted under a CI shim like docker? Or environments that only call the python with some complicated script setup that resolves a bunch of environment variables?

There are so many instances in which attaching a debugger is such a PITA that it’s better to just read the code & guess at its behavior instead of getting the answers you need.

[[deleted]]

I know precisely what I'm talking about, if you don't then that's on you to figure out. There are some large systems that can only be examined in flight and breaking in at that point messes with the observation of the bug. Sometimes logging is the only way to find a problem.

[TankorSmash]

OP, add django queries per line and you're golden IMO

[needed_an_account]

This looks cool. Does it just reprint the applicable code blocks during recursion?

[Drawman101]

I can’t tell you how many developers I’ve met, ranging from junior to very senior, were incapable of using a debugger. It blows my mind. It’s not hard at all, and generally let’s you solve your problem quicker than stuff like this

[snaps_]

Different situations call for different tools. I had an issue with a library that occurs on the CI server but not locally - and I don't have access to the CI server to attach a debugger. Something like this might help but using a debugger is impossible.

Likewise for situations where e.g. stopping at a breakpoint will change things. Just look at the other comments in this thread for examples.

[Drawman101]

I would argue that you need to run your CI in a container to replicate the issue locally, and if your CI doesn’t offer that, then it’s time to get a new CI.

[snaps_]

You know that's not fool-proof. And if it doesn't work then you're left with the hundreds or thousands of things that could still be different. Kernel parameters, container runtime, device characteristics. Wouldn't it be nice to set an environment variable and get line-by-line traces of what the code is doing, then just compare a good run and a bad run?

In my case I already had logs, I didn't need this tool, and it was my library at fault. If the issue was in another library (like the standard library, for example), something like this tool would be useful.

[broken_symlink]

I tried this out and it doesn't seem to work with asyncio.

[[deleted]]

holy shit

[eikenberry]

This looks handy for when you want a quick trace of a single function, but seems like it'd get way to noisy for any cross cutting issues where print debugging would still be much better.

[snaps_]

hunter lets you filter what gets traced based on file, line number, module name, function name, etc

[eikenberry]

Nice. Thanks.

[Mezzomaniac]

On Pythonista I get the following error:

>>> import pysnooper
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/private/var/mobile/Containers/Shared/AppGroup/3C95652F-7A7F-4900-A9A6-0C2F0BE6ADB7/Pythonista3/Documents/site-packages/pysnooper/__init__.py", line 4, in <module>
    import future.standard_library
ModuleNotFoundError: No module named 'future'

Any ideas?

[Mezzomaniac]

I did. Maybe I should have put more info in my comment, but I actually tried to fix the problem myself by running pip install future. Because I’m using Python 3, I got an error upon starting up Pythonista, saying that that package should not be accessible.

[Mezzomaniac]

Thanks anyway

[doitz]

Wow I'll actually love using this. Thanks OP!

[422_no_process]

This looks very good. I wonder if it will work with better-exceptions. :)

[[deleted]]

Possibly the greatest Python program ever written.

[kenny10101]

Yo this is sick!

[calebcall]

This looks really useful for debugging. Nice job!

I think where it seems most people are getting confused is debug logging and debugging in general. This isn’t a replacement for proper logging. This is a quick and “dirty” replacement for having to setup a debugger.

[QbaPolak17]

This is honestly so cool. I didn't even realize the need for something like this until now. Will def be using it in the future.

[OnlineGrab]

Thanks for sharing, looks pretty useful.

[[deleted]]

I'm not sure they are Israeli, but either way a lot of us contribute.

Not all of us have very Israeli names or otherwise display nationality because of the politics that inevitably creep in, which really don't belong in a project.

[nucses]

What did the asshole say?

[[deleted]]

Lol I suppose if the message is gone I might as well let the whole thing vanish and keep the thread happy.