o, I've been prodding code. As a matter of fact, I have (mostly) written a client library for creek, in Common Lisp. It was, not ioverly surprising, quicker to write than the Python library. Part of that is down to "I am more used to it", but parts is the ability to skip verbiage.
Most of the protocol glue is handled liek so:
(defmacro defprotofun (namedes (&rest args) &optional doc) (let ((fname (if (symbolp namedes) namedes (car namedes))) (pname (if (symbolp namedes) namedes (cadr namedes)))) `(defun ,fname ,args ,@(if doc (list doc)) (send (list ',pname ,@args)) (parse (creek-read *server-stream*)))))
(defprotofun take (item)) (defprotofun (list-maps listmaps) () "Return all maps defined on the server")
This is because the protocol is designed to be human-friendly and quite close to what you'd do in code, so the "trivial" functions are (essentially) "build a protocol string, ship to server, read response, parse response" (object creation and object cacheing is part of the parsing stage).
After I wrote the first two glue functions, i noticed that they were, effectively, identical and thouhg "Ah, macro time!". I then realised that a few of the protocol command were somewhat unlispish, so the macro got modified to accomodate a (possible) split between "lisp function name" and "protocol call". Then I added the option to add doc-strings.
As soon as the server is slightly more ready and a bit more tested with both client libraries and test-installed, there will be tarballs (one for the python stuff and a signed package suitable for asdf-install).