Thanks for the notes, much appreciated!
Right. However, I see tasks holding on to their environments before they finish as a feature, not an edge case. For example, you can start an async task from Elixir and immediately discard your env:
Snex.pyeval(env, """
import asyncio
loop = asyncio.get_event_loop()
loop.call_soon(some_async_task)
""")
Inside, some_async_task can even send messages back to BEAM processes with snex.send(), so starting tasks without blocking is a useful pattern for Snex.
You’re right, in the current iteration it could be an incrementing integer. At an early point in the design, I had other processes sending commands directly to the port, so ID generation was decentralized. I still want to have that option open for the future.
16 random bytes is around the same entropy as UUIDv4, so I defaulted to that. Now that I think about it, it could also be an :erlang.unique_integer() instead for 64 bits of space, although shared with other users on the node.
Good idea!
Correct. The usual pattern would be exactly to prepare an env and repeatedly reference the object from the env. With various opts of make_env/3 you can also copy Python objects between the envs.
I think it makes sense to be able to list running tasks and cancel them from Elixir side. Even a task stuck in an infinite loop with no awaits might be cancellable using OS signals.
If you search around for “elixir python” or “erlang python”, there’s a lot of projects that tackled this through C-level integration and are unusable today as they required constant maintenance to stay “fresh”. PyErl was one such project implementing C-node Python.
Making a C-node out of Python is less of a maintenance burden than directly integrating CPython API like pythonx does, but it still requires tracking Erl_Interface which is changing between BEAM versions, sometimes in breaking ways.
An important design goal of Snex is to stay evergreen as much as possible, so the current version is likely to still be usable with Python 3.17/Elixir 1.21/Erlang 30.
Thank you!
