[[!meta title="Swanky Python: Interactive development for Python"]] [[!meta copyright="Copyright © 2025 Scott Zimmermann"]] [[!inline pages="internal(2025/info/swanky-nav)" raw="yes"]] # Swanky Python: Interactive development for Python Scott Zimmermann (he/him) - [[!inline pages="internal(2025/info/swanky-before)" raw="yes"]] Project repository: I'm working on a development environment for Python based on Emacs' SLIME mode for Common Lisp. In this talk I'll demonstrate some of its features, like an object inspector, interactive backtrace buffer, thread and async task viewer, and function tracer. I'll also discuss its implementation and limitations, along with future directions for the project. This project aims to bring a Lisp and Smalltalk inspired style of development to Python. You get a faster feedback loop by developing inside a running python process without needing to restart your program and lose state on changes, allowing you to immediately inspect the results of code you write. We can also provide more advanced tooling based on runtime introspection, as we have more information available at runtime than is available to traditional tools based on static analysis of source code, mainly we have the actual values of variables rather than just their types. About the speaker: Python is eating the world. Emacs is eating my computing environment. I'm attempting to get them working together. ## Discussion / notes - Q: Does swanky-python work with Sly? - A: It doesn't, Sly is great but I went with slime for a few reasons: - I wanted to use some cool stuff from slime-star - I actually think there's good potential with slime's presentations that sly removed. - The main feature of sly missing from slime is stickers. slime-star provides something similar in being able to recompile a function with an expression traced, but I think for python it'll be better to integrate with dape for debugging - In recent years slime has been more actively maintained in terms of bug fixes and such. - Q: Does this work with Hy? ([https://hylang.org](https://hylang.org), lisp syntax for Python) - A: I actually first wrote this in Hy. [https://codeberg.org/sczi/swanky-python/src/commit/6d8f4e0c8000c931746edd0fb442704dff853492](https://codeberg.org/sczi/swanky-python/src/commit/6d8f4e0c8000c931746edd0fb442704dff853492) is the last commit before I switched back to python. - Though even when the swanky python backend was written in Hy, it was still targeted at editing python code, not Hy. Implementing it in Hy just made the implementation a bit easier, as the slime "protocol" is just slime sending lisp forms to the swank backend to evaluate, so to write the backend in python we need to implement a lisp interpreter (swank_eval in server.py), which we already have in Hy. - To make it work for editing Hy code would require some changes on the backend, around evaling code, returning source locations, and autocomplete. But most would stay the same, so I think it could be made to support both without needing to fork a separate project. I don't plan to use Hy or work on it. When writing lisp I'd rather write CL, and when writing python I'd rather use standard python syntax. But if someone wants to add Hy support I'd be happy to merge it and assist a bit. - Q: Where can I find a list of Slime-like interfaces for other languages? - A: I don't know that a slime-like interface really exists for any languages outside of the lisp and smalltalk family. I made a list of some of those at [https://codeberg.org/sczi/swanky-python/src/branch/main/Hacking.org#headline-63](https://codeberg.org/sczi/swanky-python/src/branch/main/Hacking.org#headline-63) - Q: Is there an IRC channel for swanky-python? If not, are you interested in creating one? - A: Good idea to have, I just made #swankypython on libera - Q:How would this integrate with python notebooks such as marimo? - A: I've never used marimo, just jupyter, but it looks nicer so I'd like to try it out sometime. The most basic integration would be to just run swanky python within the notebook. That way you would use the notebook as normal, but get the interactive backtrace buffer in emacs on any exception, and be able to use the inspector, nicer repl, etc. A more complete integration would probably be based on emacs-jupyter but I haven't looked into it yet. - Q: Why not org babel as well? +1 for org-babel with this, would be awesome - A: That'd be great and probably not much work at all. I just tried evaling python code as a "lisp" block, since babel for lisp calls slime-eval, and it dies with an exception because I haven't implemented swank:eval-and-grab-output in swanky python yet. Maybe it's just needed to implement that and then configure babel for python src blocks to use slime-eval rather than running with org-babel-python-command. - Tangentially, did you see Kent Pitman's recent moves to introduce his common lisp condition system to python? E.g. about resuming execution after an exception. He showed it some sunday lispy gopher climate. In my opinion, reach out to [https://climatejustice.social/@kentpitman](https://climatejustice.social/@kentpitman) since you asked for contact about lisp-style python exception restarts which he has worked on recently. - I hadn't seen that, thanks, it's super interesting to hear the old legends talk. Here's the link for anyone else: [https://medium.com/@screwlisp/live-interview-with-kent-pitman-incoming-216092e24f44](https://medium.com/@screwlisp/live-interview-with-kent-pitman-incoming-216092e24f44) - But a condition system is a bit of a separate issue from the exception restarts I'd like to have. A condition system can be implemented without any changes to the runtime, in any language with dynamic scope and first class functions. And dynamic scope can be emulated in any language with global variables, so people have implemented Common Lisp (CL) style condition systems as libraries for many languages. If this was used universally in place of the language's native exceptions, it would give the ability to drop into a repl at the point of an otherwise uncaught exception, but not the ability to restart execution from any stack frame. Smalltalk has traditional exceptions and not a CL like condition system, but its debugger does provide this ability, as does the JVM and v8 debuggers. In CL this ability (sldb-restart-frame in slime) isn't provided by the condition system, but in SBCL for example by internal functions in the sb-debug and sb-di packages. - It'd be interesting to experiment with a condition system in Python, but what I'm more interested in is the ability on any runtime error, to be able to fix the bug and restart execution from any stack frame.  - Amazing work! - [https://slime.common-lisp.dev/doc/html/](https://slime.common-lisp.dev/doc/html/) (anyone who doesn't have this bookmarked) - This is really cool, I am amazed how much functionality you have implemented! I hope I can start using this in my day job! - Very very impressive. I will definitely try to use this in my workflow. I love the Lisp development style. - very impressive. I am also working on a Python IDE with a python process and a webview to host the python runtime and display the IDE, but I am very far behind in terms of features. I just made the reload system work and the code(AST)->html renderer - Neat, if you publish it send me a link! - Definitely going to give it a try! I've been missing interactive since learning python many years ago, even before I knew Common Lisp existed and one of the primary reasons why Common Lisp replaced python as my go-to language - Such a package alone would automatically make Emacs a much better option than something like PyCharm. - I found it very funny how he showed M-x doctor But very interesting talk! [[!inline pages="internal(2025/info/swanky-after)" raw="yes"]] [[!inline pages="internal(2025/info/swanky-nav)" raw="yes"]]