Waaat :D. This is so nice. I used to use python-ls[0] for similar, but something about it that I can't recall broke for me and it's no longer maintained. Adding to my debugging arsenal which primarily consists of snoop[1] and pdbpp. Only thing I'd like for wat now is maybe an ipy widget for even easier object exploration in Jupyter.

I'm also really appreciating the base64 exec hack. All my years in Python I never thought of or came across it until now. I'll totally be using it for some things :).

[0] https://github.com/gabrielcnr/python-ls [1] https://pypi.org/project/snoop/

Ah this looks fun! I use "dir" all the time with python, and find it more useful than official documentation in some cases where documentation is not great.

Surprised there isn't more innovation and new tools like this around python's interactive shell given it's one of the real strong points the language has.

Looks like a fancy version of good old icecream. https://github.com/gruns/icecream

If you never heard about it, scroll to the bottom to https://github.com/gruns/icecream#icecream-in-other-language...

These kinds of tools are useful.

Twenty years ago I wrote an object introspector for Zope ;)

Nowadays, I'm using devtools daily, and icecream and q occasionally. I'll give wat a try.

> from wat import wat

Given the cool nature of this project, I'm surprised they don't offer simply "import wat" with identical usage syntax. Thus inviting curious users to wat/wat in order to discover the trick...

This looks super useful, but I was wondering if I'm the only one bothered by this recent trend of overloading completely unrelated operators (here the `/` operator) in the name of legibility.

One might suggest adding:

  try:
      from wat import wat
  except ImportError:
      pass

Wow, this is the kind of tool that would have been a game changer when I was learning python; being able to see what is happening under the covers is part of the critical path for me to learn a language, and native python debugging is underwhelming, at best.

Instead I just installed pry and became a rabid ruby fanboy, but this might get me to give it another go.

the author is using the Python inspect module of the stdlib under the hood to provide the functionality, of course with a lot of value-add.

see inspection.py in the wat module.

it has this on line 2:

import inspect as std_inspect

> If you want to quickly debug something, you can use this inspector without installing anything, in the same session.

> Load it on the fly by pasting this snippet to your Python interpreter

The idea of having a project's readme include a full copy of the project itself as base64'd compressed data is pretty ingenious!

especially for a project like this where you may not have had the foresight to preload it into the environment where you most need it

rich.inspect has been my go-to for this. Comes pre-installed in a vanilla Colab kernel too

I wonder if there's something like this for Lua. It doesn't have Python's built-in conveniences for introspection like `help()`.

Python's biggest weakness is the lack of a function that shows you how exactly a variable looks like. the var_dump (php, ha!) works like wonders. The best library ever created for Python ;). and now wat is also looking to be a close contender for best helping hand.

This is incredible

Looks great! And it would make for a great addition to Jupyter lab. I actually can't believe there is still no decent variable explorer bundled in

Is there similar tool for typescript/javascript ?

Given the natural built-in introspection capabilities of the language, I never understood why something like that wasn't also a built-in part Python.

I mean the number of times I've bumped on json not being able to dump the content of an object is just infuriating given how flexible Python is.

I'm definitely giving this a whirl.

dir(), help() and now adding wat to my toolbox to help debug!

Now available from AUR: https://aur.archlinux.org/packages/python-wat-git

Is there something similar for Javascript?

Re: Insta-load

Please don't do this. Exec'ing arbitrary, obfuscated code you just copied from the internet directly in a running environment is such a bad idea it shouldn't even be suggested.

At the very lease please put huge warnings around this section to let people know that it is a horrendously bad idea and they do it at their own peril.

Maybe it's just me but I just use a proper debugger. Debugpy and VSCode work fantastically.

In a previous company I set things up so that when there's an uncaught exception it will automatically start a VSCode debug session and connect to it.

Here's the extension: https://github.com/Timmmm/autodebug/

Unfortunately the Python part of that is not open source but it was only a few lines of code - should be easy to recreate. That repo does contain a C library that does a similar thing.

You might just say "why not just run your program directly with the debugger?" and yeah that is better when you can do it, but I'm working with complicated silicon verification flows that are often several layers of Python and Make, followed by a simulator (e.g. Questa or VCS) that itself loads the library you want to debug. Very difficult to make debugging work through all those layers, but it's quite easy to write some code at the bottom of the stack that says to a debugger "I'm here, debug me!".

It important to remind everyone that you can already do something similar via the build-in function help(). For example, if I run help({1}) I get the documentation for a set, running help(set.add) gives the documentation for the add() method, etc. You can even preview objects that you haven't imported by using strings(ex. running help('numpy.ndarray') will correctly give you the documentation, provided numpy is installed in your current python environment). It's pretty helpful and doesn't require installing anything extra

I'm normally a big fan of python operator overload hacks, but why are we doing `wat / foo` instead of just `wat(foo)` ?

Looks like a great tool. Will start playing with it whenever I have to dive into an existing project again.

One thing I'd like to note, though, is that most engineers (at least around and including myself) would be triggered by the "Insta-load" example of executing base64 encoded (and thus obfuscated) code.

This is interesting. I'm wondering what compelled the author to use the division magic method for arguments instead of the more intuitive and commonly used approach to passing parameters.

[flagged]

[flagged]

[dead]

[flagged]