#231 RFE; Add/enhance python bindings.

[Alec Leamas]

There is a pypi/gtihub lirc-python project. It seems to solve the basic tasks. but lacks support for sending etc. Perhaps we could just make some PR to this to add the missing funcs, or possibly fork it and include it in the main project. Anyway, we need a more complete set of python bindings.

[Bengt Martensson]

Suggestion: Write a Python version of the sendir program. One way to to this is as a translation of the LircClient. "Should" only take a few hours ( :-) ).

[Alec Leamas]

This is actually a good idea. A better implementation of irsend + bindings we actually maintain. Later, though.

[William Manley]

See our implementation of SEND_ONCE in Python here: https://github.com/stb-tester/stb-tester/blob/7736613/_stbt/control.py#L175-L281

[Alec Leamas]

This is actually some really nice python code. You are good at this.

Now, the need here is a generic python module which basically allows receiving , sending and simulating data besides some low-level "process command", roughly on the same abstraction level as lirc_client. I can see these parts in yoor code, but it seems to need some refactoring into generic and documented bindings + more specialized test code.

Thoughts?

[Alec Leamas]

BTW, the official documentation for the socket interface is the lircd manpage. IIRC, there are some updates which certainly are not available the the technical.html document.

[Bengt Martensson]

Here is my implementation of "irsend in Python". Looking forward to you feedback.

[Alec Leamas]

Don't have the time for a full review right now, just q quick feedback:

• I'm currently working with the receive part. It requires some C bindings, and reveals some nasty lirc_client.c bugs.
• So, this sending part sort of fits the overall puzzle quite well.
• My plan is to publish a python library in lib/. Thus, this work needs to be splitted to a library and a cli part.
• A descent library needs to support more than blocking read (although a timeout certainly helps. My current thinkinng is that the output connection should expose get_fileno() for multplexed applications and has_data() for threaded ones.
• This tool culd be called irtool. This makes it less of an issue that it's not compatible with irsend. The purpose is to expose the complete socket API, not just to send.

[Bengt Martensson]

My plan is to publish a python library in lib/. Thus, this work needs to be splitted to a library and a cli part.

The "library" consists of the three classes therein, the "cli-part" is what is outside (after `if name == "main":). I have been very careful to make the design here clean in this sense,

This makes it less of an issue that it's not compatible with irsend.

Since the current Lirc irsend is hardly a carefully designed interface, rather a quick hack, I did not even try to make it completely compatible, or even "as compatible as possible".

[Alec Leamas]

Since the current Lirc irsend is hardly a carefully designed interface, rather a quick hack, I did not even try to make it completely compatible, or even "as compatible as possible".

Agreed

[Alec Leamas]

Just FYI: Current library sketch: https://paste.fedoraproject.org/518476/48335969

[Alec Leamas]

Pushed a new feature branch called 'python' (sic!) The top commit says:

    python-bindings: feature complete.

    main parts lib/lirc_client.py and lib/pylirc_client.c: Allows
    reading and sending button events from python.

    Documentation in the API docs, look for "Python bindings" under
    Modules.

    Proof of concepts in doc/python-bindings and tools/irtool. The
    latter duplicates and extends irsend.

irtool is basically your CLI part built on top of "my" library. Have massaged that code to make it pass the static checkers. Your FSM lives in lirc_client.py.ReplyParser. All this is shamelessly stolen, and as I write I recognize I need your copyright on this before we merge it.

This work has revelaled more bugs, some of which fixed in the same branch. Need to file a few of them.

Thoughts?

[Alec Leamas]

@Bengt: I note that your irsend code carries a GPLv3+ license. The rest of lirc is GPLv2+. Could you possibly re-license your code to GPLv2+ to simplify things?

[Bengt Martensson]

I have changed the license. Please make sure you are "stealing from" the most recent version. Some comments:

• I see we are actually having quite different agendas. I do not really care for "python bindings" for an even growing system, I want to supply a lean way (one file, no non-standard dependencies!) for a user, possibly on (remote) system without Lirc installed, possibly non-Linux, to access an existing lircd, both command line and API.
• "irtool" is a very bad name. Just Google for it, and you will see.
• There is presently no irtool[.py] in git, branch python.

[Alec Leamas]

I have changed the license.

Thanks!!

I see we are actually having quite different agendas. I do not really care for "python bindings" for an even growing system,

Indeed we have. My focus is to provide a simple API for others. The (for now named) irtool tool is like a proof of concept. But, an important one, it's a subset of the lirc-ng tool and much easier to expand/maintain.

That said, I have still not made uo my mind whether this should be a separate project or not. There are pros and cons. The "normal" way would be to create a separate pckage.

I want to supply a lean way (one file, no non-standard dependencies!) for a user, possibly on (remote) system

Which works fine for receiving raw keypresses and/or sending stuff. But, accessing the lircrc translations cannot reasonable be re-implemented, it needs to use the native lirc libraries. And, after all, from an application point of view this is a core interface.

"irtool" is a very bad name.

Indeed. hm... not irsend, this is more general. lirctool?

There is presently no irtool[.py] in git

Oops.... fixed

[Alec Leamas]

I do not really care for "python bindings" for an ever growing system

This has sort of haunted me. The remark is on-spot.

However, there are many reasons to actually include the API part in lirc. The irtool is another story. For now, my plan is just to include it in doc/

This leaves us with two use-cases:

• "Your": Light-weight, possibly remote, not requiring lirc installed.
• My: basically irsend-ng, a generalized irsend supporting the complete socket interface w emhamced syntax and overall usability.

For now, one basic conclusion is that neither of these tools should be named irsend (nor irtool).

[Bengt Martensson]

I think a light-weight "Lirc client" (funcionally approximately like irsend), that is independent of the Lirc package would be a quite nice thing to have -- also for systems that cannot or do not want to install the full Lirc. IMHO, my LircClient pretty much satisfies this. (See also ApiExample.py). Docu is missing though... (BTW, this is roughly a Java version.)

I think that receiving raw key presses is another issue alltogether. (It is not part of my agenda :-) ) Ideally, lircd should be considered as an event source, sending events (over ???) to an evet dispatcher.

[Alec Leamas]

I think a light-weight "Lirc client" (funcionally approximately like irsend)

This is kind of a contradiction. "irsend" is about sending data, "lLirc client" lenders it name from the lirc_client library. Which primarely is used toi receive data, notably the application strings which requires a native extension

I think that receiving raw key presses is another issue alltogether

What I have called raw keypresses in this context is the strings displayed by irw. I'm not aware of any application using them besides Kodi (which suffers some bad limitations because of this). So, this is what you receive without problems today., but it's not generally useful.

IMHO a python library not exposing access to the application strings is unusable.

IMHO, my LircClient pretty much satisfies this.

That it not to say that your stand-alone irsend isn't useful. And "my" irtool doesn't really add anything att this point more than a testccase for the API. Not sure about what to do with it. One possible solution is to ship it with docs, where there already are some much smaller test snippets, notably irw.py and ircat.py

A lot of open isssues, indeed.

[Bengt Martensson]

This is kind of a contradiction.

Not really. I think I have already said that I am aware that "Lirc client" is used in two different senses, which is potentially confusing. That is the only "contradiction". Anyhow, if you have better suggestions for names, say it.

What I have called raw keypresses in this context is the strings displayed by irw. I'm not aware of any application using them besides Kodi (which suffers some bad limitations because of this). So, this is what you receive without problems today., but it's not generally useful.

IMHO a python library not exposing access to the application strings is unusable.

A better question is "what should be the public interfaces"? IMHO, raw key event should not, Also not if KODI presently uses it. But again, my interest is the long-term solution.

[Alec Leamas]

A better question is "what should be the public interfaces"?

Indeed.

Actually, I think the interface provided by the LircdConnection, which basically just wraps lirc_nextcode + lirc_code2char) is the right interface, striking a balance between being backwards-compatible and using the python strengths.

It implements LIRC's general idea, still the right one: "Give me next button press, translated to a string usable for me" And python makes it possible to package it in a reasonable way., hiding most of the C malloc/free madness.

A possible alternative would be to implement the same interface as an Iterator. I have looked into it, but not really given it a fair chance.

[Alec Leamas]

And, having this python API in place, implementing e. g., web service (the Node.js solution) should be a breeze).

What I'm saying is that the main interface is the UNIX domain socket. After alll this is Linux InfrarRed Control, and there are some 20-40 packages in the main repos requiring LIRC and that socket. That sort of defines a starting point. Besides that it is also fast (FWIW) and, important, safe. Anything with an open tcp port is a security issue, which is a burden to handle.

[Alec Leamas]

Fixed in [ba530e]. Closing