serial-toolkit 0.2.0__tar.gz → 0.3.0__tar.gz

{serial_toolkit-0.2.0 → serial_toolkit-0.3.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: serial-toolkit
-Version: 0.2.0
+Version: 0.3.0
 Summary: Wire mechanics for RS232 device drivers: framing, pacing, exclusivity, sequence anchoring, dispatch, reconnect, and liveness behind a callback API
 Author: Ben Bangert
 Author-email: Ben Bangert <ben.bangert@nabucasa.com>

{serial_toolkit-0.2.0 → serial_toolkit-0.3.0}/pyproject.toml

@@ -2,7 +2,7 @@
 # Distributed as "serial-toolkit" on PyPI ("serialkit" is blocked by PyPI's
 # name policy); the import package stays `serialkit` (see tool.uv.build-backend).
 name = "serial-toolkit"
-version = "v0.2.0"
+version = "v0.3.0"
 description = "Wire mechanics for RS232 device drivers: framing, pacing, exclusivity, sequence anchoring, dispatch, reconnect, and liveness behind a callback API"
 readme = "README.md"
 license = "MIT"

{serial_toolkit-0.2.0 → serial_toolkit-0.3.0}/src/serialkit/errors.py

@@ -15,7 +15,12 @@ class SerialKitError(Exception):
 
 
 class ConnectionLostError(SerialKitError):
-    """The serial connection dropped (EOF, write failure, probe timeout)."""
+    """The serial connection could not be opened, or dropped.
+
+    Raised by ``start()`` when the transport cannot be opened (the transport's
+    exception is the ``__cause__``), and by in-flight waits when the session
+    is lost (EOF, write failure, probe timeout).
+    """
 
 
 class CommandTimeoutError(SerialKitError):

{serial_toolkit-0.2.0 → serial_toolkit-0.3.0}/src/serialkit/link.py

@@ -221,14 +221,22 @@ class SerialLink:
     async def start(self) -> None:
         """Connect, start dispatch, run ``on_connect``, then supervise.
 
-        A failure connecting or in the first ``on_connect()`` propagates out of
-        ``start()`` after symmetric teardown; the reconnect loop only
-        supervises a session that started successfully.
+        A failure to open the transport is raised as
+        :class:`~serialkit.ConnectionLostError` with the transport's own
+        exception as its ``__cause__``: transports raise their own types for
+        an unreachable port (not all of them ``OSError``), and a caller that
+        retries on the kit's error must not have to know every one of them. A
+        failure in the first ``on_connect()`` propagates as raised, after
+        symmetric teardown. Either way the reconnect loop only supervises a
+        session that started successfully.
         """
         if self._monitor_task is not None:
             raise RuntimeError("already started")
         self._stopped = False
-        await self._open_session()
+        try:
+            await self._open_session()
+        except Exception as exc:
+            raise ConnectionLostError(f"could not open connection: {exc!r}") from exc
         try:
             await self._handler.on_connect()
         except BaseException: