GDB pretty printing w/ Python is really powerful, but also it's ridiculously high friction compared to Microsoft's .natvis.

Completely aside from any syntactic whatever, you can't (safely) load any ol' Python script in a project's repo, but you can safely load up associated .natvis files, which makes Microsoft's solution vastly superior for library users.

And there's really no reason that GDB and LLDB can't just implement .natvis support out of the box. (Yes, I know there are Python libraries that add a subset of .natvis support to GDB, but that doesn't solve the "out of the box" part at all.) Or hell, if they really hate Microsoft (who doesn't?) then implement their own declarative debug visualizer format.

(This post brought to you by me using Clang 22 for _Defer via mingw and now having to write *****ing Python to make my pure C project comfortably debuggable.)

@seanmiddleditch I've noticed that a lot of people sort of forgot the power in "I just have a data file I can carry around that can be safely loaded because its restriction is the point" and just keep doing things like "What if I gave someone access to an unrestricted python / Lua / JavaScript / {etc.} interpreter as part of my program?".
@seanmiddleditch The worst part is they don't even try to lock things down. Like, oh, yeah, sure, here's my Lua interpreter with direct access to the whole file system. And I can access the FFI so I can touch every single system call if I really try. Awesome. Thanks. This won't come back to fuck us all over!
@thephd I've been working on this for a game scripting runtime and it's pretty challenging - a lot of the scripting systems out there just give full privilege. What we ended up doing is using the embedded browser out-of-process (and its sandbox, with a deliberately broken proxy configuration) to run Javascript and then communicate to it over JSON-RPC, but this has unfun performance impact. There's probably ways to bust it, too, but at least we tried...