1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
|
[[!meta title="Swanky Python: Interactive development for Python"]]
[[!meta copyright="Copyright © 2025 Scott Zimmermann"]]
[[!inline pages="internal(2025/info/swanky-nav)" raw="yes"]]
<!-- Initially generated with emacsconf-publish-talk-page and then left alone for manual editing -->
<!-- You can manually edit this file to update the abstract, add links, etc. --->
# Swanky Python: Interactive development for Python
Scott Zimmermann (he/him) - <mailto:sczi@disroot.org>
[[!inline pages="internal(2025/info/swanky-before)" raw="yes"]]
Project repository: <https://codeberg.org/sczi/swanky-python/>
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"]]
|
