jonathan_s

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.)

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.

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.)