From 5173e42c5a3e707f5e0edaa31a11001e1282f8bb Mon Sep 17 00:00:00 2001 From: Sacha Chua Date: Sun, 28 Dec 2025 19:30:54 -0500 Subject: add sat dev discussions --- 2025/talks/swanky.md | 109 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 109 insertions(+) (limited to '2025/talks/swanky.md') diff --git a/2025/talks/swanky.md b/2025/talks/swanky.md index de939730..be639835 100644 --- a/2025/talks/swanky.md +++ b/2025/talks/swanky.md @@ -40,6 +40,115 @@ 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"]] -- cgit v1.2.3