Hacker News Reader

Comment by melted | Hacker News Reader

What for? What benefits does the use of Python confer in this case?

README.md is a good place to check:

Compared to tmux

To some extend, pymux is a clone of tmux. This means that all the default shortcuts are the same; the commands are the same or very similar, and even a simple configuration file could be the same. (There are some small incompatibilities.) However, we definitely don't intend to create a fully compatible clone. Right now, only a subset of the command options that tmux provides are supported.

Pymux implements a few improvements over tmux:

There is a completion menu for the command line. (At the bottom of the screen.) The command line has fish-style suggestions. Both Emacs and Vi key bindings for the command line and copy buffer are well developed, thanks to all the effort we have put earlier in prompt_toolkit. Search in the copy buffer is highlighted while searching. Every pane has its own titlebar. When several clients are attached to the same session, each client can watch a different window. When clients are watching different windows, every client uses the full terminal size. Support for 24bit true color. (Disabled by default: not all terminals support it. Use the --truecolor option at startup or during attach in order to enable it.) About the performance:

Tmux is written in C, which is obviously faster than Python. This is noticeable when applications generate a lot of output. Where tmux is able to give fast real-time output for, for instance find / or yes, pymux will process the output slightly slower, and in this case render the output only a few times per second to the terminal. Usually, this should not be an issue. If it is, Pypy should provide a significant speedup. The big advantage of using Python and prompt_toolkit is that the implementation of new features becomes very easy.

That doesn't answer the question though. Why not just add all (or some) of the aforementioned stuff to tmux? Tmux is an established, widely used piece of software. Any improvements would be much more appreciated there.

You could say the same about screen vs tmux (or endless other software clones). Projects like these help drive innovation on both sides. Competition, if you like.

Besides, Pymux is Python while tmux is C. I'm sure you can appreciate that adding a Python API to tmux would be non-trivial, both code-wise and politically.

Author of tmuxp here, a python API and config manager on top of tmux(1).

You can see the quickstart at https://tmuxp.readthedocs.org/en/latest/quickstart_python.ht... and the API documentation at https://tmuxp.readthedocs.org/en/latest/api.html.

You can see the testcases we cover use real tmux sessions and monitor the state of the session / window / panes to assert the API functions correctly. https://github.com/tony/tmuxp/tree/master/tmuxp/testsuite

As for pymux, Jonathan Slenders' work on ptpython [1] and prompt_toolkit have been quite nice when working with shell_plus in django or debugging python projects. He's good in this area. Agreed that it's a nice thing to have pymux there.

And agreed that adding native language extensions (python, ruby, etc.) to tmux would be complicated code-wise and perhaps not in the spirit of what it aspires to be. That said, on the tmuxp side of things, a lot could be improved. For example, switching tmuxp to use control mode (-C) and filing smaller patches to expand control mode's events in tmux(1).

[1] https://github.com/jonathanslenders/ptpython

In my experience, Screen is a crashy piece of garbage.

tmux is comparatively rock solid.

But what's the innovation? Adding the python API?

Not everything has to innovate. I understand it would be more useful to you and I if it did innovate, but there isn't some prereq for posting to hacker news that your project has to be innovative.

I personally find this project interesting to see, although I won't be using it.

The comment I was replying to specifically mentioned it.

Spend the 30 seconds required to read the ancestor comment explaining what it has enabled WRT prompt toolkit.

Look at the list of features that pymux has that tmux doesn't.

That's innovative? Ok, for some loose def of innovation.

you seem to have confused innovation with invention. but that's beside the point. you seem to think that software needs to be either to deserve existance. looks like you're in the minority with that opinion, the rest of us is quite happy with iterative, gradual improvement. we consider it better than sticking with whatever the first shot at an implementation managed to hit.

It literally does. "The big advantage of using Python and prompt_toolkit is that the implementation of new features becomes very easy."

Because doing it in C might be a waste of time

How so? You instantly get the benefits out to a huge user base.

Same goes for Python

Pure Python is the difference. It runs anywhere python runs. Same can't be said for a compiled C program.

It's maybe not a "big" why, or one you care about.

Isn't the Python interpreter implemented in C? How could Python run someplace that C can't?

I think he means the exact same Python script can be run directly on any environment that has Python installed if written correctly, in contrast to a C program which has to be recompiled on various environments to be able to run.

One of them is. And ability to interpret Python is requirement for any python program to be able to run. Being able to build and deploy a c lib is not.

So, someone has made python run on Foo platform, lets say a watch. If I have a pure python program I can run it on that watch with no more fuss. If I have to rely on a c library then I have to get that ported to Foo platform, maybe dealing with developer keys and making "authorized" signed binary, etc, etc. Pure python is orders of magnitude easier.

That is why "Pure Python" is a thing.

Several standard libs come in pure python and C versions cause pure python is an advantage / requirement for some use cases. And speed is for others.

Python as a language is implemented on almost every platform out there- You can just take this source code and run it there, instead of compiling for the target hardware.

I'm not following you -- are you saying that Python runs where C doesn't, or something else ?

I'm saying Python is already installed in places that would require a lot of effort to port and compile C vs just running some.py file.

"python some.py" is (in some cases) vastly easier than porting/compiling/signing C code.

This is discussed in the readme. One point:

> The big advantage of using Python and prompt_toolkit is that the implementation of new features becomes very easy.

What new features are necessary in tmux? Isn't it enough to be able to split, and connect/disconnect to a session?

This is a frequent and IMHO mostly weird question. I understand the "why reimplement XYZ in $YOURFAVORITELANGUAGE just to have XYZ in $YOURFAVORITELANGUAGE" sentiment but there is an equally valid benefit in using uniform tool stacks. I am a Python developer. I am comfortable working in other languages, and contributing patches to tools written in other languages, but there is a real benefit to having a full toolset written in a single language even if some of those tools are less developed than their counterparts.

This is besides the benefit that even though you might not need tmux in Python, having tmux in Python might have created tmux-the-library which someone might later need.

(I haven't yet tried this but I plan on doing so. On an unrelated note, thanks to the author for making this pure Python, and for caveatting "it's not as fast as C" with "but try PyPy").

Not sure I quite get what the benefit is in having all my tools in one language.

Here's a decent start of a more elaborated explanation: http://pyvideo.org/video/83/djangocon-2011--keynote---glyph-...

From the link: Just like pyvim (A Vi clone in Python.), this is another experiment. A hobby project

Extensibility via Python scripts instead of custom config syntax maybe?

Well that seems to be of very marginal utility to me, but I concede that it might be a much bigger deal for others.

It's probably not even that hard to embed the CPython interpreter into tmux and allow extensions written in python. If you just wanted to write python extension modules, embedding Python and then wrapping the tmux api with Python using cffi is likely a winner.

Reply on news.ycombinator.com