78 karma · joined January 3, 2014
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.
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.
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.
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.)
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.
pymux --truecolor
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/...
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.)
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.
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?)
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.
I noticed. You're not doing it wrong. It's a bug and it will be fixed asap.
(Not yet on Pypi, we we'll get there.)
The idea is indeed that ``ptpython`` could become the terminal front-end for IPython.
The only thing on which ``prompt_toolkit`` is focussing, is reading input from stdin and returning it to the application. IPython is a very powerful execution environment, but the current command line interface which uses GNU readline lacks decent multiline editing and syntax highlighting.
There is a proof of concept of what the integration could look like: https://github.com/jonathanslenders/python-prompt-toolkit/bl... But in the end it would be nice to have this as a part of IPython itself.