Lomond is a Pythonic WebSocket client library designed for reliability and ease of use, turning a WebSocket connection into an orderly stream of events. It distinguishes itself by providing an event-driven model without requiring explicit threads or callbacks for basic usage. The current version is 0.3.3. However, the library appears to be abandoned, with the last release in 2018 and no recent development activity.
pip install lomondVerified import paths — ran on the pinned version, not inferred.
This example demonstrates how to establish a WebSocket connection using Lomond, send a text message, and print received text messages. Lomond provides an event-driven loop where different `event.name` values indicate connection status or received data. The loop will terminate upon disconnection or explicit `break`.
Consider using alternative, actively maintained WebSocket client libraries for Python (e.g., `websockets`, `websocket-client`) that are tested and compatible with modern Python versions. If you must use Lomond, restrict your environment to Python 3.7 or earlier, but be aware of the security implications of using an End-of-Life Python version.
For new projects, strongly consider using an actively maintained WebSocket client library. For existing projects using Lomond, assess the risks, consider migrating to a current library, or be prepared to maintain any necessary fixes internally.
Always wrap your event handling logic in `try...except` blocks within the `for event in websocket:` loop to catch and handle exceptions gracefully, ensuring explicit `websocket.close()` calls if necessary.
If your application needs to perform long-running tasks or concurrent I/O alongside WebSocket communication, encapsulate the Lomond event loop within its own dedicated thread to prevent blocking the main application thread.
Install the library using pip: `pip install lomond`
Inspect the raw `event.text` from the WebSocket event to understand the actual message format. If the server is not sending pure JSON, custom parsing logic will be required. For `socket.io` connections, specialized client libraries might be necessary.
Ensure that the received `Text` event actually contains valid JSON before attempting to access `event.json`. It's good practice to check `event.name` to confirm the event type and potentially use a `try-except json.JSONDecodeError` block when accessing `event.json`, or explicitly check if `event.json` is not `None`.