Jonathan Slenders
@jonathan-slenders.bsky.social
Software engineer at Cisco. Python, Rust, prompt_toolkit, databases, concurrency, parsers, Linux, algorithms ...
Do you know Leptos? It uses wasm rather than JS as a target, but amazing for doing front-end dev in Rust. I've used it for some time, and except for some incompatibilities between major version upgrades, I haven't seen any bugs.
September 2, 2025 at 8:15 AM
Do you know Leptos? It uses wasm rather than JS as a target, but amazing for doing front-end dev in Rust. I've used it for some time, and except for some incompatibilities between major version upgrades, I haven't seen any bugs.
That sounds like something that should go in the stdlib at some point.
June 6, 2025 at 8:45 PM
That sounds like something that should go in the stdlib at some point.
This is technically not even possible I think. The function that `sys.settrace` calls can't yield back to the currently running event loop, because this function is not async itself. The event loop is frozen while we are on a breakpoint. And asyncio event loops are not reentrant.
March 14, 2025 at 9:35 PM
This is technically not even possible I think. The function that `sys.settrace` calls can't yield back to the currently running event loop, because this function is not async itself. The event loop is frozen while we are on a breakpoint. And asyncio event loops are not reentrant.
Sure! Thanks!
December 20, 2024 at 10:32 AM
Sure! Thanks!
I couldn't help but notice that at least in my currently installed neovim version (2nd December 2024), this built-in terminal emulator doesn't propagate DEC mode 2031 to nested nvim instances. Given that you were working on mode 2031, do you think this is something that will be fixed.
December 19, 2024 at 9:27 PM
I couldn't help but notice that at least in my currently installed neovim version (2nd December 2024), this built-in terminal emulator doesn't propagate DEC mode 2031 to nested nvim instances. Given that you were working on mode 2031, do you think this is something that will be fixed.
Wow, I wish you all the best!
December 15, 2024 at 8:21 PM
Wow, I wish you all the best!
Have you used the datetype library? I believe this provides a type-safe compatible wrapper around datetime that prevents accidentally mixing timezone-aware and timezone-naive timestamps.
December 13, 2024 at 8:33 AM
Have you used the datetype library? I believe this provides a type-safe compatible wrapper around datetime that prevents accidentally mixing timezone-aware and timezone-naive timestamps.
`set(s) - {"0", "1"} == set()`
December 4, 2024 at 3:53 PM
`set(s) - {"0", "1"} == set()`
Maybe later ;)
December 3, 2024 at 9:22 PM
Maybe later ;)
This is perfect! Now we need to get everyone (Wezterm,Alacritty,tmux,...) to support this. It's so little effort for such a big gain.
December 3, 2024 at 3:30 PM
This is perfect! Now we need to get everyone (Wezterm,Alacritty,tmux,...) to support this. It's so little effort for such a big gain.
@willmcgugan.bsky.social : Do you know about this capability?
December 2, 2024 at 8:45 PM
@willmcgugan.bsky.social : Do you know about this capability?
Does this work in tmux (or any other terminal multiplexer)? As a developer of a TUI library I'm also interested in any docs around this DEC mode.
December 2, 2024 at 8:43 PM
Does this work in tmux (or any other terminal multiplexer)? As a developer of a TUI library I'm also interested in any docs around this DEC mode.
This is really impressive what you have here.
November 29, 2024 at 11:09 AM
This is really impressive what you have here.
True, but I think the main issue is that by applying structured concurrency to threads (so no callbacks), we'll end up with many more (often short lived) threads than typical threading applications. OS threads probably have too much overhead here.
November 24, 2024 at 9:50 PM
True, but I think the main issue is that by applying structured concurrency to threads (so no callbacks), we'll end up with many more (often short lived) threads than typical threading applications. OS threads probably have too much overhead here.
Yes, true, but (1) they are always shielded from cancellation and (2) I believe `from_thread` blocks the underlying *OS* thread. This can exhaust the thread pool. And less of an issue (3) if you call a sync library that does IO in `to_thread`, this library won't use `from_thread` to schedule its IO.
November 23, 2024 at 7:52 AM
Yes, true, but (1) they are always shielded from cancellation and (2) I believe `from_thread` blocks the underlying *OS* thread. This can exhaust the thread pool. And less of an issue (3) if you call a sync library that does IO in `to_thread`, this library won't use `from_thread` to schedule its IO.
I still have to read about project Loom, but I guess there will be options. Like allowing cancellation to happen at *every* Python instruction; at the start of a function; at explicit cancellation points; or having code entirely shielded from cancellation. The latter probably being the default.
November 22, 2024 at 9:26 AM
I still have to read about project Loom, but I guess there will be options. Like allowing cancellation to happen at *every* Python instruction; at the start of a function; at explicit cancellation points; or having code entirely shielded from cancellation. The latter probably being the default.
Yes, so do I. But there's a strong point to be made that having this behavior prevents asyncio from scaling over multiple threads (like e.g., Tokio in Rust). Maybe asyncio will remain single-threaded, and if we want multi-core (structured) concurrency, micro threads will be the way to go.
November 22, 2024 at 9:21 AM
Yes, so do I. But there's a strong point to be made that having this behavior prevents asyncio from scaling over multiple threads (like e.g., Tokio in Rust). Maybe asyncio will remain single-threaded, and if we want multi-core (structured) concurrency, micro threads will be the way to go.
Also having "await" be both a cancellation point as well as a context switch is somewhat arbitrary. There are many situations where you want to have one without the other. I think these are distinct concepts and it only makes sense to be explicit about the cancellation points. (cc: @mitsuhiko.at )
November 21, 2024 at 9:00 PM
Also having "await" be both a cancellation point as well as a context switch is somewhat arbitrary. There are many situations where you want to have one without the other. I think these are distinct concepts and it only makes sense to be explicit about the cancellation points. (cc: @mitsuhiko.at )
Once we get rid of the GIL, concurrent applications should be able to leverage multiple CPUs. Relying on code between two "await"-points being atomic no longer works and the only thing "await" signals is a context switch for I/O, which is something the interpreter already knows without the "await".
November 21, 2024 at 8:54 PM
Once we get rid of the GIL, concurrent applications should be able to leverage multiple CPUs. Relying on code between two "await"-points being atomic no longer works and the only thing "await" signals is a context switch for I/O, which is something the interpreter already knows without the "await".
Yes, because function coloring is no longer an issue. Think about it the other way around, what does "await" really bring? And those things, why would they not be possible with "normal" Python threads? (Not OS-level threads, but threads as they could be exposed through the Python interpreter.)
November 21, 2024 at 8:39 PM
Yes, because function coloring is no longer an issue. Think about it the other way around, what does "await" really bring? And those things, why would they not be possible with "normal" Python threads? (Not OS-level threads, but threads as they could be exposed through the Python interpreter.)
I imagine this would be implemented by having a user provide explicit cancellation points. E.g., a call to `threading.cancellation_point()` which will raise a `CancelledError` or something like that.
November 21, 2024 at 9:46 AM
I imagine this would be implemented by having a user provide explicit cancellation points. E.g., a call to `threading.cancellation_point()` which will raise a `CancelledError` or something like that.
Not completely a noop for backward compatibility I think. "await" needs to become a cancellation point, and a lock should be acquired between two "await" points because people rely on that being atomic.
November 20, 2024 at 9:40 PM
Not completely a noop for backward compatibility I think. "await" needs to become a cancellation point, and a lock should be acquired between two "await" points because people rely on that being atomic.