[HN Gopher] Show HN: Wat - Deep inspection of Python objects
___________________________________________________________________
Show HN: Wat - Deep inspection of Python objects
Author : igrek51
Score : 117 points
Date : 2024-07-25 16:18 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| blackbear_ wrote:
| 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
| languagehacker wrote:
| 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.
| lakshayg wrote:
| Interesting choice indeed. It looks like it supports the
| traditional approach as well
|
| > wat object can quickly inspect things by using the division
| operator (to avoid typing parentheses). A short, no-parentheses
| syntax wat / object is equivalent to wat(object).
| enragedcacti wrote:
| I think it makes a lot of sense in the context of a live
| interpreter. Wrapping and object in help() or dir() is an
| annoying set of movements vs. just pressing 5 keys with no
| modifiers (Home, w,a,t,/). It makes its feel much more like a
| magic command without actually needing it to be magic. The dot
| modifiers are also convenient compared to passing kwargs imo.
| pvg wrote:
| The README suggests for easier typing in interactive use.
| igrek51 wrote:
| It's the parentheses that drove me crazy. As people already
| noted, it's for faster typing, at the cost of the division
| magic as you noted. If it's more familiar to you, it works with
| `wat(object)` syntax as well.
| AcerbicZero wrote:
| 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.
| Aeveus wrote:
| 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.
| kajecounterhack wrote:
| I was just about to post that it freaked me out a little, but
| wasn't sure if I was going to be the only one.
| Spivak wrote:
| The insta-load is fine. You're supposed to save the snippet,
| decode and uncompress it, look at it to see what it does and
| that it's completely self-contained uncontroversial Python code
| and copy-paste _your version_ that you bookmarked. It 's super
| short.
| tacoooooooo wrote:
| not hard to see it
|
| with open('wat_source.py', 'w') as f: f.write(zlib.decompress(b
| ase64.b64decode(code.encode())).decode())
| fuzztester wrote:
| just so that it is clear for everyone, including newbies here,
| does the insta-load code snippet work like this:
|
| the author has encoded the wat module's source code into
| base64. the snippet shown decodes that back into python code,
| and then executes it on the fly, thus having the same effect as
| importing the wat module in the normal python way?
| igrek51 wrote:
| Yes, that has the same effect as installing the package. So
| if you feel uncomfortable, you can either install the pip
| package (and of course review the installed code) or review
| the decoded string before executing it. It's not that
| obfuscated anyways, it's still quite readable.
| blueboo wrote:
| rich.inspect has been my go-to for this. Comes pre-installed in a
| vanilla Colab kernel too
| timhh wrote:
| 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!".
| chis wrote:
| This is incredible
| alkh wrote:
| 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
| fuzztester wrote:
| and the dir() built-in Python function.
| guruparan18 wrote:
| Also most advanced IDE's do this better and lot more to
| troubleshoot/debug.
| igrek51 wrote:
| You're completely right. `dir()` does the same in terms of
| functionality. In fact, my tool makes use of `dir` under the
| hood. I just wanted to make it more readable, and to combine
| `dir`, `type`, `repr`, `len`, `inspect`, etc. into one easily
| accessible place.
| wantsanagent wrote:
| 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.
| tantalor wrote:
| This is so bad it should be nsfw-blurred and you have to click
| 2 buttons to even see it.
| timdorr wrote:
| I'm not a Python dev. Why would they do this? This is giving
| vibes of malware embedded into npm packages.
| skeledrew wrote:
| Convenient way to quickly add extra debugging capability
| without rerunning. It isn't much different from the many
| `curl example.com/install.sh |bash` you see around. It's up
| to the user to check things out before running.
| oreilles wrote:
| How is it any different than installing the package via pip ?
| Not only most people won't check the source before running the
| code, but there is also no way to be sure that the code shipped
| by pip is the one you read on GitHub...
| Retr0id wrote:
| I'm normally a big fan of python operator overload hacks, but why
| are we doing `wat / foo` instead of just `wat(foo)` ?
| JulianChastain wrote:
| `wat(foo)` also works. The author says he implmented the `wat /
| foo` syntax to allow you to more quickly use wat by avoiding
| parentheses
| contravariant wrote:
| Probably so you can run a big complicated formula in the REPL
| and easily prepend `wat /` to it to inspect what's going on.
|
| Same reason jupyter notebooks allow you to prepend '?' or '??'
| to inspect a variable (though not expressions, in that respect
| this syntax is better)
| fuzztester wrote:
| 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
| benrutter wrote:
| 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.
| pjot wrote:
| There's the help() function as well! Super helpful!
| skeledrew wrote:
| 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/
| maxmcd wrote:
| Is there something similar for Javascript?
| enriquto wrote:
| > 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...
| igrek51 wrote:
| "import wat" would be great, but Python has some restrictions
| about modules not being callable. That's why I ended up with
| longer `from wat import wat`. Not sure but maybe this would be
| more convenient `import wat; wat.wat / object`
| ilyagr wrote:
| I wonder if there's something like this for Lua. It doesn't have
| Python's built-in conveniences for introspection like `help()`.
___________________________________________________________________
(page generated 2024-07-25 23:01 UTC)