jonathan_s's comments

If you can, best is to always spawn them in a task group (either using anyio or Python 3.11's task groups).

This prevents tasks from being garbage collected, but also prevents situations where components can create tasks that outlive their own lifetime. Plus, it's a saner approach when dealing with exception handling and cancellation.

I've gone very recently through a rewrite from Rocket to Axum and very much love it so far.

The initial motivation was the need for web socket support, which Rocket doesn't have (yet). But I love how simple it is, and also that it does not want to be the entry point of the application. (I like an http server that's a library that can be embedded at any place in the application.) Another great thing is the examples/ directory in the Axum repository.

I had to use the latest version from GitHub though to get some of the features I needed, but maybe that's not the case anymore.

Same experience here. Canvas rendering is much faster for terminal apps if done well. I think also VS code uses a canvas for its terminal because its superior performance.

No, there is nothing to remember. Every decent HTML templating engine these days will handle all free form text as unsafe and escape it automatically. The same for SQL libraries.

Input sanizitation doesn't work, because it doesn't know what is dangerous and what is not dangerous. That depends completely on the output domain, and at the point where the inputs are received, the output domain is often unknown. Data can flow through many layers of business logic and then be passed to an SQL query, an HTML templating engine or anything else.

If you don't consider database strings to be free form text when constructing HTML, then there's a good chance there will be vulnerabilities anyway, regardless of whether any sanitization has been applied.

The article is fine.

Hi, I'm the author of prompt_toolkit. A library that does something similar for Python. Don't hesitate to copy anything you need. It took me a few iterations to get the API as I wanted.

One thing I underestimated was the importance of having all readline key bindings available. People are really sensitive when certain functionality that they are used to is missing. (And you've no idea how much functionality there is in readline until you have to implement it.)

Also check out pymux: https://github.com/jonathanslenders/pymux

Yes, but it's unsafe for another reason. The new syntax can be verified statically by tools like Pylint. A call to locals() is hard to verify.

The locals() function itself could for instance have been replaced by something else. When using locals(), you won't know until execution time if a local variable, required for the interpolation is missing. Even worse, linter tools (pylint, pyflakes, jedi, ...) are now going to tell you that certain variables are not used, and people are going to remove it without thinking that somewhere a locals() call is going to use it. This is very bad. Actually, the effects of using locals() cannot be verified statically, even more because locals() is also a writable dict.

For f-strings, the name bindings are static, and editors are going to understand it while editing.

Yes, it does support true color. It's disabled by default, because not all terminals support it, but if you want 24bit, do:

pymux --truecolor

(author). This is the first release of Pymux. It should be stable and usable for daily work. However, don't hesitate to create a GitHub issue in case you feel that it lacks some features/responsitivity or when you'd like to see something different. Expect to see more progress in the coming months. Jonathan

Sure it's true. And software written in C or assembly language often also performs better than those written in Python.

@amjith: we should do that indeed. If you don't have the time, I'll help you doing it later on.

Hi, thanks for the suggestions! Actually, the internal representation, is completely separate from the layout. It's not in another repository, but it's decoupled.

The key bindings are also separate. Getting emacs bindings is not much more than changing this line [0]. Only adding the bindings for the window management and emacs command line is still to be done. (I know that emacs is actually much more than only its key bindings, but you know what I mean.)

The rendering is also independent. There are two backends: vt100 terminals and the windows console. (Honesly, my main focus is vt100, but any render back-end is possible. I think even graphical)

The same for the event loops by the way, it can run on a couple of event loops. For instance asyncio.

Documentation will follow. prompt-toolkit has already quite a lot of examples, and there's a lot of documentation in the code itself. But I agree that we should keep improving.

Cheers!

[0] https://github.com/jonathanslenders/pyvim/blob/master/pyvim/...

Can you tell me what terminal application you are using? Does it happen as well in a new terminal?

It's a blackbox re-implementation. In Python, things are done different from C and there are other libraries are available (Pygments for instance). I also don't want to claim that it is as powerful as Vim is. But it should be stable, easy to install, and especially usable for Python development.

Yes, it should normally work with all unicode characters. (If not, please file a bug.)

This could be confusing. '?' is for searching backwards, '/' for searching forward. Because we are in a multiline environment, I preferred the Vi keybindings instead of the readline bindings (where '/' goes backwards.)

Also the ControlX-ControlL sequence can complete a line based on the history. (Type "imp"C-X C-L and you get your last import.)

>> It would be really helpful, to just search for some keyword and have the last occurence...

In Vi-mode, use ControlX-ControlL after typing the start of the line, then you have line based completion, which also completes from the history.

Thanks for the feedback.

About "daw": it looks like I forgot about that. To be fixed, but right now use "diw" instead. (Please create a github issue if there are some other important key bindings missing.)

At the moment, I don't know yet about auto-reloading in IPython, but that's worth looking at.

About the PYTHONPATH, that's easy to fix. (Should we always add the current directory to the path in a REPL?)

Thank you for the feedback. I'll add an option to turn off the automatic autocompletion.

I'm sorry about this, at the moment there is no Windows support.

However the architecture of the library decouples the input and output from the rest, so it should be possible to plug in something to make it compatible with the Windows terminal.

For me personally, it doesn't have priority, but maybe in the future I will have a look.