Visit our site at podcastinit.com for more show notes and news.
Brief Introduction
- Date of recording – May 17th, 2015
- Hosts – Tobias Macey and Chris Patti
- Follow us on iTunes, Stitcher or TuneIn
- Give us feedback! (iTunes, Twitter, email, Disqus comments)
- Overview – Interview with Jonathan Slenders
Interview with Jonathan Slenders
- Introductions
- How were you first introduced to Python? -Chris
- What inspired you to create the python-prompt-toolkit?
- What are some design considerations that you made when building prompt-toolkit?
- Make minimal use of inheritance
- Overly strong coupling
- Better clarity for the API of your library
- Completely event driven / asynchronous
- No global state
- ptpython completion benefits from asynchrony – The jedi completion library is too slow – completion happens in its own thread
- Make minimal use of inheritance
- You have built a number of projects that use the prompt-toolkit as a core component, did you have them in mind from the beginning, or are they experiments to test the capabilities of the toolkit?
- Do you intend to bring PyVim to feature parity with Vim, or is it just intended for experimentation?
- Short answer: Don’t know – but will probably never be in full parity with Vim
- What inspired you to create ptpython and why did you choose to make it a stand-along project rather than extending iPython?
- How difficult was it to integrate with IPython and what were the benefits?
- IPython has its own event loop – this presented difficulties as prompt-toolkit has its own as well
- What are some of the most interesting uses that you have seen of the prompt-toolkit?
- PyVim – really challenged the design
- pgcli
Picks
- Tobias
- Chris
- Jonathan Slenders
- Belgian Beer
- Rochefort
- Western European Folk Dancing
Keep in touch
- Belgian Beer
- Twitter – @jonathan_s
- GitHub – jonathanslenders
[00:00:14]
Unknown:
Hello, and welcome to podcast.init. We're recording today on May 17, 2015. Your hosts, as usual, are Tobias Macy and Chris Patti. You can follow us on iTunes, Stitcher, or TuneIn Radio. You can also find our RSS feed on our site at podcastinit.com. And please give us feedback. You can leave reviews on iTunes, contact us by Twitter, email us at hostspodcastinit.com, or leave us comments on our show notes. Today, we're going to be interviewing Jonathan Slenders. So, Jonathan, can you please introduce yourself?
[00:00:51] Unknown:
Yeah. Sure. So I'm Jonathan. I'm a Python developer. I did quite a lot of open source projects. Currently, my I I worked for Cisco mainly as a Python coach and, Python trainer. Yeah. I think that's about it.
[00:01:11] Unknown:
How were you first introduced to Python?
[00:01:14] Unknown:
Okay. That, should be already a long time ago. I'm not entirely sure, but I guess, between 10, maybe 15 years ago that I started playing with it. And I don't remember what I did exactly, but I think then I I dropped Python for for a while. I started experimenting with a few other languages. And then later, I started using Python again. I think it should have been about 7 years ago that I started working for a bit more serious work, And then I created Python, web application stack a bit similar to Django, so a templating engine and, HTTP, etcetera.
But but I I dropped that project. We have we have now Django, which is much better, but I learned about a lot by doing that. And, yeah, from then on, I've I've been using Django for all my projects. But I'm not entirely sure so when exactly I started and and what the the reason was. But I'm actually happy that I I chose Python in the end.
[00:02:25] Unknown:
What inspired you to create the Python prompt toolkit?
[00:02:30] Unknown:
Okay. Yeah. That's also, a long history. It should have been a few years ago that I was working on tmux on tmux. So do you know tmux? It's a terminal multiplexer.
[00:02:46] Unknown:
Yeah. Absolutely.
[00:02:48] Unknown:
Yeah. Okay. So I was working on a few patches for tmux and, to to add, like, the paint title bars so that each paint and demux could have its own title bar with the description of the process running inside it with maybe some statistics and other things. And it was quite a lot of effort, but but in the end, I got there. But I had a hard time getting this merged into the the upstream because it's, runs on so many different platforms. It's it's expected to be really stable. So in order to to add some new functionality, it should be really tested. And at that time, I did not have the energy, and I did not want to do the effort to to test all, my patches everywhere.
And, that was about the same time that we that asyncio for Python was developed. It was still, I think, in the alpha phase. And I started you developing a clone in Python using asyncio asyncio for all the processing chronization, and and that worked pretty well. I had things like vertical splits, horizontal splits, a nice view on the things. But then at some point, I needed to have a command line. So at the bottom of tmax, you have a command line where you can enter commands to to do things with tmax. And the most obvious way, of course, to do that was to use, the rate line library for Python and to use the byte bindings for that. But there was 1 issue and it is that the readline bindings of Python, they have some assumptions about what the input and output is.
And demux actually has a client server architecture. So the user interface actually runs in another process than the tmax session itself. And it was, similar for my Python clone of tmax. So I could not really use grid line bindings. And that was the point where I started implementing grid line in pure Python. And that was the start of prong toolkits that developed a lot. That went through several iterations. And, in the end, actually, I I I dropped the team at this project because, it's also exciting. I I got to develop, quite a lot of other things.
So that's a bit of the the history.
[00:05:29] Unknown:
Very cool. You know, I I was actually gonna ask you my next question. You've already kinda answered this, though. What prompted you to create the prompt toolkit when more traditional tools were already available? Because you've already you've already gone over with that. So what were some of the design considerations that you made when building the prompt toolkit?
[00:05:51] Unknown:
Yeah. Maybe, a few. I think 1 thing that's really, present in the whole library is that I try not to use too much of inheritance. And, yeah, you we could start talking about a shared state between burnt and child objects, which is like a very strong kind of coupling. But another reason for me not to use too much inheritance is like I think that inheritance is not like a really nice API to expose as library. So if you want your users to use your library and you expect them to inherit from your classes and to add functionality to it, it's not really that obvious which things are considered private, which things are public, and which things are actually intended to be customizable.
And on the other hand, if you expose callables either as functions or constructors of classes as an API, I think that's a much nicer way because then you for a function, it's really clear what the input is. The inputs are the parameters of a function. So if you want to parameterize 1 piece of functionality, I think it's really nice to do that just as a function or in case when it's a class to use the constructor for that instead of expecting someone to use inheritance for parameterization. And, I think that's something that many Python projects, how I feel personally, are not always doing it the easiest way for the for the end user.
So in Python, it's really easy to use inheritance. It's an obvious way to better materialize things. Like, you have the base behavior and you inherit from it. You implement the changes in the child class. But another way to do that is to use the constructor of a class to accept all the parameters of that class and expect the end user just to create an instance of that. So that's 1 of the design considerations I made and I think that's what makes in this particular case a nice clean api. Maybe, another thing is that prompt toolkit, it's completely event driven.
So there are a few things which are asynchronous, like the auto completion is completely asynchronous in btpytons, so the Python REPL implemented on top of the library, the when the dot strings are shown or when the function's signature is shown, these are also things which are asynchronous. And they are obviously done through threading, but the interaction between the main threads and the threads doing the auto completion, it's all going through an event loop. And that makes it really easy or safe to do interactions between several treads to avoid things like race conditions, etcetera. So that way, there's no need to do any kind of logging.
And maybe 1 last design consideration that I had through the whole library is that there's no single global state. So for every single component in the whole library, it's possible to create multiple instances. And maybe that sounds weird for a rate line replacement because normally you only have, like, 1 input. But, I think in the future, it should also be possible to use, like, maybe an SSH server or a telnet server, which runs in 1 process. And every time when a client connects to the server, they should be able to view 1 such interface.
So that's the reason for not having a global state, and it's also something that I was missing in the rate line bindings. The rate line bindings of Python, they have a really strong opinion about what is input and output. It's just std in and std out. And so it's impossible to have multiple red line instances in Python. But in prod toolkit, that's that's possible.
[00:10:38] Unknown:
That's really interesting. It it almost makes me think of with regards to your, you know, whole point about minimizing the use of inheritance. I forget whether it was gang of 4 or I've I know I've seen it in a bunch of places where they will say always say favor composition over inheritance And Yeah. Exactly. You know, talk about how people in object oriented programming languages, it's like inheritance is the shiny toy, and they feel like they really wanna use it. And they end up overusing it and end up really complicating their designs unnecessarily. It seems like this might be a really excellent example of how you've avoided that.
[00:11:15] Unknown:
Yeah. Maybe. And and 1 thing which is nice in Python, that is that you have abstract base classes. So Python encourages shallow inheritance. And I think just 1 layer of inheritance is okay. So you have your base clause, which is an absolute base clause, which does not have a real implementation, but just specifies the interface of a thing. So in prompt toolkit, for instance, you have, like, an autocomplete interface. So if you want to write your an autocompletion algorithm and you want to plug it in in the library, you just implement that interface, and you do it by inheriting from the abstract base class, which defines the the interface for the completion.
But that base class does not have any single implementation. It just specifies the the expected behavior of that class. And I think that's that's a nice way to do it in in Python.
[00:12:15] Unknown:
And and actually, can you go back and and and just explain for me a little bit? I know what the what led into this asynchrony discussion was you talking about PT Python and how it uses asynchrony. I know you mentioned something about the doc strings, but, I mean, it's a it's a REPL. Right? Like, how does why does an interactive REPL like that, how does it benefit from having an asynchronous prompt library under the hood? And if if you already explained that previously, I apologize, but it it seems like there might be some interesting tidbits there.
[00:12:50] Unknown:
Yeah. Maybe for the docstring, it was not really necessary to do it asynchronously. But for the auto completion, in any case, it was because the auto completion, it can be really heavy. Python is a extremely dynamic language. And if you want to do auto completion of source code without executing anything, so you don't want to do a lookup of the attributes of an object because doing a lookup has possibly side effects. So at completion, it's done through analyzing the source code, and I'm using, an amazing library for that. It's jedi. And jedi works by analyzing the source code.
And it's not, like, really slow, but slow enough to do to not do it on every single key press. And so, yeah, you want users to be able to type while we do the auto completion and background before the user noticing it. And, actually, that's the only reason because just a general library is slightly too slow to do it then real time on every single key press.
[00:13:54] Unknown:
That is that is really neat. So so, basically, I'm typing along, and let's say I say double quotes, hello world dot. So now I've created a string, and I wanna I wanna get the completion for all the potential methods that come off that string. How does that can you give me a sense of how that is working asynchronously? So you're saying Jedi is too slow to check with every keystroke. What happens when I hit that dot? How does the asynchrony kick in and enable Jedi to be fast enough to make the user feel like it's kind of a real time response?
[00:14:33] Unknown:
So on every single key press, actually, I start the auto completion in another thread. But as soon as there is already an auto completion going on, I don't restart an autocompletion on the next keypress. So that way there's always 1 autocompletion running in the background. And when it comes back and it sees that the input has not changed, it knows that the autocompletion is the 1 that applies to the current input. So if you go on and you type too fast, for a while, the audio completion running in the background will do the audio completion of a few keys keys first back, but we just just ignore that.
And then in the end, when there's a small pause and maybe that 1 has finished, we restart the art completion so that we always have the latest auto completions available.
[00:15:26] Unknown:
That's a really smart way of doing it. So you basically have found kind of the perfect match between giving real time sort of, like, I'm typing, and it's guessing what I'm gonna be typing next. And you've actually finished, and you're sitting there, you know, thinking about it or whatever, and it's now actually gonna give you the correct completion for the class that you've actually typed. So you get the full the full completion of exactly what you want. That's that's a really great design, it sounds like.
[00:15:56] Unknown:
Yes. Yes. That's that's more or less how it works need.
[00:16:00] Unknown:
So you've built a number of projects that use the prop toolkit as the core component. And did you have those in mind from the beginning of working on the library, or are they primarily used as experiments to test the capabilities of the toolkit and some of the things that you can do with it and maybe find edge cases that need to be addressed?
[00:16:19] Unknown:
Yeah. So, actually, I I had none of them in mind when I started pronto kit. Because actually pronto kit, it was a tool that I wanted to use for my daemon's clone in Python, which, actually, I abandoned. So all of the other projects that I built on top of it, they were just things that came into my mind later on. And bt Python, the Python rebel, was obviously the most obvious thing to do with such a library. So that was the first thing that I did. And then a few other projects came, just out of interest and to see, to test the capabilities.
[00:17:00] Unknown:
And could you elaborate on what some of those other projects were and some of the inspirations behind them? I know you did the PGCLI and PIVIM, which are both definitely very interesting in their own right. So just wondering if you can give a little bit more insight into what inspired you to create them and what benefits you've had from using those applications
[00:17:20] Unknown:
than Yeah. The way. BJ CLI was not created by me. Okay. It's, actually a friend. It's this, and I had a lot of correspondence with him while building, BT Python or, prompted it, I mean. And, I got a lot of feedback and, from him, and he was, like, my first test user, even before it was public. And I think at some point, he got, interested in in using the library, and he decided to create pjcli, so a postgres rebel for that library to test it. And now he's working on a MySQL client. He, got a Kickstarter campaign, funded, with a few $1, 000, so that was really nice. And, hopefully, we will see a MySQL client soon.
But, yeah, I I created, bt Python. Later, I created b t p d b. So Python debugger like p d b, but then using the p t Python front end with, the nicer to completion, etcetera. That's still a highly experimental project. It needs to get a bit more lost, but we will get there. I I have to work in proof of concept, and, I will probably improve it somewhere during the next, months. And then we have Python. And that came actually after a question of my talk at Python Fosten. So a a few months ago, I had the chance to to speak at Fosten. It's a Belgian open source conference. And 1 of the questions from the audience was that someone asking me, if you have all these capabilities like prompt look it has very nice key binding system. It has a very nice layout engine.
It has a very nice rendering engine and and a few other things. And he said, well, if if you have already all these capabilities, how far are you actually from a real editor? And then I started experimenting with it. And, actually, it was not that much of an effort. And after a few months, just in my free time, I had Python as a as a proof of concept, which is now really usable. I use it actually as my primary editor just to to test the capabilities and to to get confronted with its limitations. It's not yet like, the real VI replacement, but it's it's nice.
[00:20:08] Unknown:
That actually that actually brings us into our next question. We had we had actually thought to ask you, you know, do you intend to keep evolving pyvim and and eventually make it into something that really could be in feature parity or close with Vim? Or is it just kind of an experimental test bed for you to show how the prompt toolkit can be used in an actual application?
[00:20:32] Unknown:
Yeah. Actually, I don't know yet. We will see, but Vim is really a real complex application. It has so many capabilities which are not, like, visible at at at the first, first looks. There are so many hidden features. So I think I will never be in parity with, the real of him, and I think NioVim may be a better candidate for people looking for a real replacement. But I think what I I will do with Python is I I want to have something that is easy to install and that feels natural to vi users and which has at the same time a good Python integration, like syntax highlighting, auto completion, and the things that you need for Python development. Maybe at some point, even a a debugger.
But, I I will see. I don't know yet.
[00:21:31] Unknown:
So going back to the PT Python, how difficult was it to integrate it with IPython, and what benefits did you see from doing that integration?
[00:21:43] Unknown:
The benefits are that IPython has a lot of additional functionality like their the built in metrics. For instance, if you do the person sign pdb space on, you can automatically call the pdb prompt when an error happens. IPython has many more such nice built ins. Also, the I really like the percent find it if you want to benchmark a small piece of code. And I did not really see p t Python as a replacement for IPython, but I want to be able to use it actually as a nicer front end for IPython. And that was when I created pt IPython. But the integration itself, it was not that hard.
It's not the nicest way I did it. It's maybe still kind of hacked to the way I did the integration, but it works really well, except for 1 thing, and that is that IPython has its own event loop. For instance, if you want to do want to show a graph like, for instance, with NumPy or scipy, it's it's possible to to plot a graph or maybe matplotlib, I think it is. And, then ipython can show the the graph at the same time when you run repl. And I bite the nosset by using its own event loop and by patching the the input stream. And given that prod toolkit has its own event loop, I I was not able or not yet able to integrate both event loops.
So ptipython uses the event loop of prong toolkit, and it does not run the event loop of ipython, which makes it impossible to run or to show when there's far plots. And that's still something I have to do to to find the better way to to do that integration.
[00:23:51] Unknown:
Well, that was actually something that I was gonna ask you is, have you ever considered sort of I mean, I think PT Python is amazing and IPython is amazing. You know? It sounds like to quote an American commercial, 2 great tastes that would taste great together. Have you ever thought about talking to the to the IPython team and maybe building some of the the the the awesome PT Python interactive completion features into IPython core?
[00:24:16] Unknown:
Yeah. I I've indeed talked with, some of the IPython core developers, but, right now, that the integration is maybe, a bit idle. I we have both been busy, I think, with with other things. I've been busy lately much more at improving prompt toolkits and experimenting with Python and, looking for an even better architecture of prompt toolkits. So, the integration was maybe a bit on the pause, but, yeah, we will see. We will figure it out probably to to find a a better way.
[00:24:55] Unknown:
So, what are some of the most interesting uses that you've seen for prompt toolkit?
[00:25:02] Unknown:
Yeah. I I think Python itself probably was the the application where I really went to the limits. So that was the application where I really challenged the design. Otherwise, I think, like, the beaches CLI and and upcoming MySQL CLI will be really nice. And 1 1 other nice thing is, lately, a friend of me is developing a lot using asyncio and Python. And 1 thing for debugging an asyncio process, it's sometimes still hard to to debug an asyncio process because you don't want to have any blocking calls in it. So you don't want to have a REPL inside the async IO process because on everything else if if you're doing that.
And what he is doing, he is using an SSH server which runs inside the process, with lessons on a local socket. And he connects just, using message client to that socket to control and debug the the async IO process. And the thing he asked me was, isn't it possible to use the bt Python rebel and run that through the SSH server? And I'm going to have a look at that because I think that's really exciting if you have an SDK process and then you SSH to a local unique socket and you get a Python rebel to control another process, a Python process, which just goes on running.
So the rebel does not cause the process to to block. I think that's that's exciting.
[00:26:54] Unknown:
That is really exciting. Does your friend's project have a name? Is it is it something we can sort of watch out for?
[00:27:01] Unknown:
No. It's a commercial project that he's working on, but the SSH server is open source, and I will probably try to integrate with this SSH
[00:27:12] Unknown:
server. Well so, are there any other project we've obviously been talking about prompt toolkit and things like that and all the spin off projects. Are there any other projects that you're working on that you think might be interesting to our listeners?
[00:27:26] Unknown:
Maybe not necessarily interesting. But 1 thing I've been working on several years ago was a Python deployment framework. It is like fabric but a bit more advanced, but still not yet like SaltStack or Ansible or other Python frameworks that we have. And we use that to deploy quite a lot of Linux Ubuntu machines. But, I think maybe right now, Salt Lake could be a a better choice. And I I don't have the time anymore to
[00:28:05] Unknown:
to work a lot on that 1. Yeah. I do I do infrastructure as code work all day long, and I have to say, sometimes the community around the tool is actually more important than the tool itself. You know what I'm saying? Like, I mean, my current company uses Chef, and I happen to like Chef. And I think some of 1 of the things that makes Chef the most 1 of the things that makes Chef great in my mind anyway is the incredible ecosystem of of cookbooks and recipes that are around it. And I know the same thing is starting to happen with both Ansible and Salt. So, you know, sometimes, even if yours is better, it's like, it it probably makes sense to use the 1 that that that has the momentum in the industry.
[00:28:51] Unknown:
Yeah. Exactly. If if, you can write the best tool, but if if you don't have, the the people or the the knowledge to or the time to support all these people, you won't get anywhere. So it it's really important to to have a good community. And that's also why I'm now focusing more impromptu because I'm I really feel that that was a gap where we did not have a solution yet and which was something I liked. And so I prefer to to spend my time on that instead.
[00:29:27] Unknown:
Makes good sense. Are there any questions that you feel like we should have asked you but didn't? Something that you think that, you know, you'd that you'd like to tell us or tell our listeners?
[00:29:38] Unknown:
No. I I think you're doing a a great job, and, it's it's really nice to have a Python podcast. And, yeah, I look forward also to to the next interviews.
[00:29:51] Unknown:
Thank you. It's kinda funny that for for a long time, there were none. And then all of a sudden, we had this idea, and then, the other gentleman who does talk Python to me, he came out in the in the exact same week. So it's like we went from none to 2 in no time flat. But, thankfully, the Python community is huge, so there's there's plenty of room for both of us to thrive. So why don't we move on to the picks? This is where we have our guests as well as us go through things that we find interesting, neat, fun, tasty, whatever, things that we wanna recommend to our users or we think they might be interested in. So, Tobias, why don't you kick it off?
[00:30:29] Unknown:
Sure. So my first pick that I'm going to go with this week is a product called Vimcert, and this is a plugin for the Chrome browser that lets you basically use a Vim process or BIM style editor in any text input. So you click on a text input, hit control I, and it'll pop open an ACE editor with BIM key bindings so that you can then edit the entire contents of the text input. And then when you are done with it, you just hit colon w q just like in a VIM process and it is really useful. So I've actually been using it at work for managing some SQL queries that are being put in via a text input box, and it's much easier to do that than trying to manage it directly within the text input.
For my next pick, I'm gonna choose the Johnny Cash project, and this is a website that is a collaborative art piece and it is a music video of 1 of Johnny Cash's last recordings and people are encouraged to pick a given frame of that music video and draw it using a tool that they created. And then you can play the music video and it is a compilation of all the different frames that people have drawn, put together, and it is a really incredible experience. And you can actually choose different styles of artwork that people have done to view the video in different ways. So it's a continually evolving experience, and it's just really great fun.
My 3rd pick is going to be the movie Interstellar, And I watched that a couple weeks ago and it was really very well done, addresses a lot of interesting problems with how we're currently managing our natural resources and, you know, our ongoing discussion of space travel and colonization of remote worlds. And it also does a really good job of addressing the complications of relativity in space travel, particularly in how it relates to the main character's relationship with his children who he had to leave behind on Earth. So just really great movie, definitely worth a watch. And that's it for me this week.
[00:32:48] Unknown:
Great. Thanks, Tobias. This week, I'm gonna start off with a beer pick because I like beer, and I like really good craft beer. I just encountered a beer that is really unusual. It is called Grim Brewing's Telekinesis. It is a wild American ale. So I tend to be a draft beer snob. I don't often enjoy beer in bottles, at least when I can get away with it. I I tend to like to go to a pub and actually enjoy it right out of the keg. I just think it's a lot fresher and a lot tastier. And this beer came to me, and it looks like fizzy yellow limoncello. Cello. You know, like, for anybody who is familiar with that particular kind of lemon liqueur. So it's really interesting. It's kind of sour, kind of dry, not not sweet at all really or very very minimally so, just a little bit of hoppiness.
It's really interesting. I have to say, it's kind of in a category all its own. They call it a wild American ale. And, if you like beer and you're open minded, this is not, like, the kind of thing that if you drink Bud Light all the time, you're gonna appreciate. You have to be willing to sort of recognize that the beer world is is huge and varied, and and this is definitely something. This is an outlier. And and, thus, if you're a fan as I am, it's worth checking out. My next pick is this tool called Pandoc. It's an open source project and the idea is that it will convert documents of kind of any I shouldn't say any, of many many different formats to many, many other different kind of formats. And I started using it because, we do our show notes every week in Zoho Docs because which we previously picked because we can be collaborative about it, and we're literally the typing back and forth. But at the end, you know, we wanna transition the the picks and everything else and the questions we've asked to our our show notes website, and Zoho Docs will export a, Microsoft, you know, dot docx XML format document.
And then Pandoc will transform, transform it into markdown. So with a few minor edits, I can just put it right in the show notes site, which we run with Pelican. So it's a really handy tool. If you have a document of 1 format and you need it in another, I would definitely check it out, and the link's in the show notes. The next pick I have is 1 of those little tools that's kind of like you know, you you hear about it, you try it, you say, oh, I'll give this a shot, and then it it becomes kinda life changing. It's called Vimpager. And what this tool does is essentially, it replaces your your current pager, which is probably, like, more or less or whatever depending upon what you have configured and replaces it with VIM. And so the the really great thing about this is you don't realize how ubiquitous if you use Unix all the time, day in, day out, your pager is.
Things like looking at law like like looking at, source code control logs or reading man pages or reading long log files or whatever, and to have all the amazing text, you know, searching, manipulation, and etcetera features that VIM brings to bear. It's a really handy tool. My last pick is going to be a project another open source project called Homebrew Cask. This is for Max only, because the Homebrew package manager. But what's really cool is Homebrew Cask basically takes it to the next level. And as opposed to just open source project, which is mostly what homebrew itself is, these little packages that you can download easily, Homebrew CASK lets you install fully fledged commercial applications with Homebrew, like Chrome, like, you know, iTerm, like, various very your the all the web browsers, all the mail clients, all the apps that normally you would have to download, unpack a dot DMG file, which is the OSX specific application archive, and do the drag and drop thing with the icon.
And what's great about this from my perspective is, you know, I can write a little script. And so when I get a new machine or I walk onto a new machine, I can have it, you know, install all my applications that I want in in 1 fell swoop. So I I find it really handy. And that's it for me. Jonathan, do you have any picks for our audience?
[00:37:15] Unknown:
Actually, I forgot to choose any any picks, but I think, talking about beer, that was yours. 1st pick, I think. I think if you like beer, then you should certainly come someday to to Belgium.
[00:37:28] Unknown:
Oh, yes. Yes, indeed. I I am a huge Belgian beer fan, and I feel like I've just explored the very tip of the iceberg. I I I love Belgian beers. I I I love the kinda subtle fruitiness of them of of some of them and and the complexity, and they're just they're just great. It's not quite I'm actually I'm not sure if it's Belgian or not, but, Duchess de Bijon, that's 1 of my favorite beers of all time. And that's actually, that's I guess that's from the Burgundy region, which is not Belgium. Right? That's, like, France or something like that. I I mean, geography is really terrible.
[00:38:06] Unknown:
It it could be. I'm not entirely sure actually.
[00:38:09] Unknown:
So what are some of your favorite Belgian beers? What what what what if you if if, like, let's say our listeners get a chance to visit Belgium, what should they what should they not miss?
[00:38:19] Unknown:
I don't drink that much beer, but 1 of my favorite is probably Hushfoak. I would recommend that 1.
[00:38:27] Unknown:
Okay. That sounds great. So at some point, we'll have to get the spelling of that because I'm not sure that I will get it right on the show notes. So we can we can look it up and and and allow our listeners to, to find it. Is there anything else that you'd like to recommend? Any games that you play? Books you've read? Movies you watched? Anything?
[00:38:48] Unknown:
Good question. No. Lately, actually, I'm more like dancing a lot. We and and Belgium, we we have nice community of people doing folk dance, and that's what I like a lot. So that's more of my free time.
[00:39:03] Unknown:
No. That's fantastic, actually. So what kind of folk dancing? Morris dancing, contra dancing? Like, what is it Belgian folk dancing? Is there is there a particular a particular technique or or genre that that is germane to Belgium?
[00:39:19] Unknown:
It's, most the things we are doing is are mostly coming from Western Europe, and it's still improvisation. So it's not dancing for public and more for our own fun. And we have quite a lot of different dances. We have, couple dances. We have group dances. And most of them are originally from France, from, maybe a bit from Belgium, from Sweden, so Western Europe.
[00:39:47] Unknown:
That's great. Okay. Western European folk dancing. Sounds like fun.
[00:39:53] Unknown:
Okay. So, I think that'll do it for the picks. Tobias, go ahead. Alright. Well, Jonathan, thank you very much for joining us and taking the time to speak with us so that we could talk to you about your prompt toolkit and some of the other projects that you've been involved with. So for anybody who wants to follow you and keep up to date with what you're working on, what would be the best way to do that?
[00:40:15] Unknown:
I think maybe GitHub or maybe Twitter as well.
[00:40:19] Unknown:
Well, thank you again, and I hope you have a good evening.
[00:40:23] Unknown:
Yeah. You're very welcome. It was a pleasure.
Hello, and welcome to podcast.init. We're recording today on May 17, 2015. Your hosts, as usual, are Tobias Macy and Chris Patti. You can follow us on iTunes, Stitcher, or TuneIn Radio. You can also find our RSS feed on our site at podcastinit.com. And please give us feedback. You can leave reviews on iTunes, contact us by Twitter, email us at hostspodcastinit.com, or leave us comments on our show notes. Today, we're going to be interviewing Jonathan Slenders. So, Jonathan, can you please introduce yourself?
[00:00:51] Unknown:
Yeah. Sure. So I'm Jonathan. I'm a Python developer. I did quite a lot of open source projects. Currently, my I I worked for Cisco mainly as a Python coach and, Python trainer. Yeah. I think that's about it.
[00:01:11] Unknown:
How were you first introduced to Python?
[00:01:14] Unknown:
Okay. That, should be already a long time ago. I'm not entirely sure, but I guess, between 10, maybe 15 years ago that I started playing with it. And I don't remember what I did exactly, but I think then I I dropped Python for for a while. I started experimenting with a few other languages. And then later, I started using Python again. I think it should have been about 7 years ago that I started working for a bit more serious work, And then I created Python, web application stack a bit similar to Django, so a templating engine and, HTTP, etcetera.
But but I I dropped that project. We have we have now Django, which is much better, but I learned about a lot by doing that. And, yeah, from then on, I've I've been using Django for all my projects. But I'm not entirely sure so when exactly I started and and what the the reason was. But I'm actually happy that I I chose Python in the end.
[00:02:25] Unknown:
What inspired you to create the Python prompt toolkit?
[00:02:30] Unknown:
Okay. Yeah. That's also, a long history. It should have been a few years ago that I was working on tmux on tmux. So do you know tmux? It's a terminal multiplexer.
[00:02:46] Unknown:
Yeah. Absolutely.
[00:02:48] Unknown:
Yeah. Okay. So I was working on a few patches for tmux and, to to add, like, the paint title bars so that each paint and demux could have its own title bar with the description of the process running inside it with maybe some statistics and other things. And it was quite a lot of effort, but but in the end, I got there. But I had a hard time getting this merged into the the upstream because it's, runs on so many different platforms. It's it's expected to be really stable. So in order to to add some new functionality, it should be really tested. And at that time, I did not have the energy, and I did not want to do the effort to to test all, my patches everywhere.
And, that was about the same time that we that asyncio for Python was developed. It was still, I think, in the alpha phase. And I started you developing a clone in Python using asyncio asyncio for all the processing chronization, and and that worked pretty well. I had things like vertical splits, horizontal splits, a nice view on the things. But then at some point, I needed to have a command line. So at the bottom of tmax, you have a command line where you can enter commands to to do things with tmax. And the most obvious way, of course, to do that was to use, the rate line library for Python and to use the byte bindings for that. But there was 1 issue and it is that the readline bindings of Python, they have some assumptions about what the input and output is.
And demux actually has a client server architecture. So the user interface actually runs in another process than the tmax session itself. And it was, similar for my Python clone of tmax. So I could not really use grid line bindings. And that was the point where I started implementing grid line in pure Python. And that was the start of prong toolkits that developed a lot. That went through several iterations. And, in the end, actually, I I I dropped the team at this project because, it's also exciting. I I got to develop, quite a lot of other things.
So that's a bit of the the history.
[00:05:29] Unknown:
Very cool. You know, I I was actually gonna ask you my next question. You've already kinda answered this, though. What prompted you to create the prompt toolkit when more traditional tools were already available? Because you've already you've already gone over with that. So what were some of the design considerations that you made when building the prompt toolkit?
[00:05:51] Unknown:
Yeah. Maybe, a few. I think 1 thing that's really, present in the whole library is that I try not to use too much of inheritance. And, yeah, you we could start talking about a shared state between burnt and child objects, which is like a very strong kind of coupling. But another reason for me not to use too much inheritance is like I think that inheritance is not like a really nice API to expose as library. So if you want your users to use your library and you expect them to inherit from your classes and to add functionality to it, it's not really that obvious which things are considered private, which things are public, and which things are actually intended to be customizable.
And on the other hand, if you expose callables either as functions or constructors of classes as an API, I think that's a much nicer way because then you for a function, it's really clear what the input is. The inputs are the parameters of a function. So if you want to parameterize 1 piece of functionality, I think it's really nice to do that just as a function or in case when it's a class to use the constructor for that instead of expecting someone to use inheritance for parameterization. And, I think that's something that many Python projects, how I feel personally, are not always doing it the easiest way for the for the end user.
So in Python, it's really easy to use inheritance. It's an obvious way to better materialize things. Like, you have the base behavior and you inherit from it. You implement the changes in the child class. But another way to do that is to use the constructor of a class to accept all the parameters of that class and expect the end user just to create an instance of that. So that's 1 of the design considerations I made and I think that's what makes in this particular case a nice clean api. Maybe, another thing is that prompt toolkit, it's completely event driven.
So there are a few things which are asynchronous, like the auto completion is completely asynchronous in btpytons, so the Python REPL implemented on top of the library, the when the dot strings are shown or when the function's signature is shown, these are also things which are asynchronous. And they are obviously done through threading, but the interaction between the main threads and the threads doing the auto completion, it's all going through an event loop. And that makes it really easy or safe to do interactions between several treads to avoid things like race conditions, etcetera. So that way, there's no need to do any kind of logging.
And maybe 1 last design consideration that I had through the whole library is that there's no single global state. So for every single component in the whole library, it's possible to create multiple instances. And maybe that sounds weird for a rate line replacement because normally you only have, like, 1 input. But, I think in the future, it should also be possible to use, like, maybe an SSH server or a telnet server, which runs in 1 process. And every time when a client connects to the server, they should be able to view 1 such interface.
So that's the reason for not having a global state, and it's also something that I was missing in the rate line bindings. The rate line bindings of Python, they have a really strong opinion about what is input and output. It's just std in and std out. And so it's impossible to have multiple red line instances in Python. But in prod toolkit, that's that's possible.
[00:10:38] Unknown:
That's really interesting. It it almost makes me think of with regards to your, you know, whole point about minimizing the use of inheritance. I forget whether it was gang of 4 or I've I know I've seen it in a bunch of places where they will say always say favor composition over inheritance And Yeah. Exactly. You know, talk about how people in object oriented programming languages, it's like inheritance is the shiny toy, and they feel like they really wanna use it. And they end up overusing it and end up really complicating their designs unnecessarily. It seems like this might be a really excellent example of how you've avoided that.
[00:11:15] Unknown:
Yeah. Maybe. And and 1 thing which is nice in Python, that is that you have abstract base classes. So Python encourages shallow inheritance. And I think just 1 layer of inheritance is okay. So you have your base clause, which is an absolute base clause, which does not have a real implementation, but just specifies the interface of a thing. So in prompt toolkit, for instance, you have, like, an autocomplete interface. So if you want to write your an autocompletion algorithm and you want to plug it in in the library, you just implement that interface, and you do it by inheriting from the abstract base class, which defines the the interface for the completion.
But that base class does not have any single implementation. It just specifies the the expected behavior of that class. And I think that's that's a nice way to do it in in Python.
[00:12:15] Unknown:
And and actually, can you go back and and and just explain for me a little bit? I know what the what led into this asynchrony discussion was you talking about PT Python and how it uses asynchrony. I know you mentioned something about the doc strings, but, I mean, it's a it's a REPL. Right? Like, how does why does an interactive REPL like that, how does it benefit from having an asynchronous prompt library under the hood? And if if you already explained that previously, I apologize, but it it seems like there might be some interesting tidbits there.
[00:12:50] Unknown:
Yeah. Maybe for the docstring, it was not really necessary to do it asynchronously. But for the auto completion, in any case, it was because the auto completion, it can be really heavy. Python is a extremely dynamic language. And if you want to do auto completion of source code without executing anything, so you don't want to do a lookup of the attributes of an object because doing a lookup has possibly side effects. So at completion, it's done through analyzing the source code, and I'm using, an amazing library for that. It's jedi. And jedi works by analyzing the source code.
And it's not, like, really slow, but slow enough to do to not do it on every single key press. And so, yeah, you want users to be able to type while we do the auto completion and background before the user noticing it. And, actually, that's the only reason because just a general library is slightly too slow to do it then real time on every single key press.
[00:13:54] Unknown:
That is that is really neat. So so, basically, I'm typing along, and let's say I say double quotes, hello world dot. So now I've created a string, and I wanna I wanna get the completion for all the potential methods that come off that string. How does that can you give me a sense of how that is working asynchronously? So you're saying Jedi is too slow to check with every keystroke. What happens when I hit that dot? How does the asynchrony kick in and enable Jedi to be fast enough to make the user feel like it's kind of a real time response?
[00:14:33] Unknown:
So on every single key press, actually, I start the auto completion in another thread. But as soon as there is already an auto completion going on, I don't restart an autocompletion on the next keypress. So that way there's always 1 autocompletion running in the background. And when it comes back and it sees that the input has not changed, it knows that the autocompletion is the 1 that applies to the current input. So if you go on and you type too fast, for a while, the audio completion running in the background will do the audio completion of a few keys keys first back, but we just just ignore that.
And then in the end, when there's a small pause and maybe that 1 has finished, we restart the art completion so that we always have the latest auto completions available.
[00:15:26] Unknown:
That's a really smart way of doing it. So you basically have found kind of the perfect match between giving real time sort of, like, I'm typing, and it's guessing what I'm gonna be typing next. And you've actually finished, and you're sitting there, you know, thinking about it or whatever, and it's now actually gonna give you the correct completion for the class that you've actually typed. So you get the full the full completion of exactly what you want. That's that's a really great design, it sounds like.
[00:15:56] Unknown:
Yes. Yes. That's that's more or less how it works need.
[00:16:00] Unknown:
So you've built a number of projects that use the prop toolkit as the core component. And did you have those in mind from the beginning of working on the library, or are they primarily used as experiments to test the capabilities of the toolkit and some of the things that you can do with it and maybe find edge cases that need to be addressed?
[00:16:19] Unknown:
Yeah. So, actually, I I had none of them in mind when I started pronto kit. Because actually pronto kit, it was a tool that I wanted to use for my daemon's clone in Python, which, actually, I abandoned. So all of the other projects that I built on top of it, they were just things that came into my mind later on. And bt Python, the Python rebel, was obviously the most obvious thing to do with such a library. So that was the first thing that I did. And then a few other projects came, just out of interest and to see, to test the capabilities.
[00:17:00] Unknown:
And could you elaborate on what some of those other projects were and some of the inspirations behind them? I know you did the PGCLI and PIVIM, which are both definitely very interesting in their own right. So just wondering if you can give a little bit more insight into what inspired you to create them and what benefits you've had from using those applications
[00:17:20] Unknown:
than Yeah. The way. BJ CLI was not created by me. Okay. It's, actually a friend. It's this, and I had a lot of correspondence with him while building, BT Python or, prompted it, I mean. And, I got a lot of feedback and, from him, and he was, like, my first test user, even before it was public. And I think at some point, he got, interested in in using the library, and he decided to create pjcli, so a postgres rebel for that library to test it. And now he's working on a MySQL client. He, got a Kickstarter campaign, funded, with a few $1, 000, so that was really nice. And, hopefully, we will see a MySQL client soon.
But, yeah, I I created, bt Python. Later, I created b t p d b. So Python debugger like p d b, but then using the p t Python front end with, the nicer to completion, etcetera. That's still a highly experimental project. It needs to get a bit more lost, but we will get there. I I have to work in proof of concept, and, I will probably improve it somewhere during the next, months. And then we have Python. And that came actually after a question of my talk at Python Fosten. So a a few months ago, I had the chance to to speak at Fosten. It's a Belgian open source conference. And 1 of the questions from the audience was that someone asking me, if you have all these capabilities like prompt look it has very nice key binding system. It has a very nice layout engine.
It has a very nice rendering engine and and a few other things. And he said, well, if if you have already all these capabilities, how far are you actually from a real editor? And then I started experimenting with it. And, actually, it was not that much of an effort. And after a few months, just in my free time, I had Python as a as a proof of concept, which is now really usable. I use it actually as my primary editor just to to test the capabilities and to to get confronted with its limitations. It's not yet like, the real VI replacement, but it's it's nice.
[00:20:08] Unknown:
That actually that actually brings us into our next question. We had we had actually thought to ask you, you know, do you intend to keep evolving pyvim and and eventually make it into something that really could be in feature parity or close with Vim? Or is it just kind of an experimental test bed for you to show how the prompt toolkit can be used in an actual application?
[00:20:32] Unknown:
Yeah. Actually, I don't know yet. We will see, but Vim is really a real complex application. It has so many capabilities which are not, like, visible at at at the first, first looks. There are so many hidden features. So I think I will never be in parity with, the real of him, and I think NioVim may be a better candidate for people looking for a real replacement. But I think what I I will do with Python is I I want to have something that is easy to install and that feels natural to vi users and which has at the same time a good Python integration, like syntax highlighting, auto completion, and the things that you need for Python development. Maybe at some point, even a a debugger.
But, I I will see. I don't know yet.
[00:21:31] Unknown:
So going back to the PT Python, how difficult was it to integrate it with IPython, and what benefits did you see from doing that integration?
[00:21:43] Unknown:
The benefits are that IPython has a lot of additional functionality like their the built in metrics. For instance, if you do the person sign pdb space on, you can automatically call the pdb prompt when an error happens. IPython has many more such nice built ins. Also, the I really like the percent find it if you want to benchmark a small piece of code. And I did not really see p t Python as a replacement for IPython, but I want to be able to use it actually as a nicer front end for IPython. And that was when I created pt IPython. But the integration itself, it was not that hard.
It's not the nicest way I did it. It's maybe still kind of hacked to the way I did the integration, but it works really well, except for 1 thing, and that is that IPython has its own event loop. For instance, if you want to do want to show a graph like, for instance, with NumPy or scipy, it's it's possible to to plot a graph or maybe matplotlib, I think it is. And, then ipython can show the the graph at the same time when you run repl. And I bite the nosset by using its own event loop and by patching the the input stream. And given that prod toolkit has its own event loop, I I was not able or not yet able to integrate both event loops.
So ptipython uses the event loop of prong toolkit, and it does not run the event loop of ipython, which makes it impossible to run or to show when there's far plots. And that's still something I have to do to to find the better way to to do that integration.
[00:23:51] Unknown:
Well, that was actually something that I was gonna ask you is, have you ever considered sort of I mean, I think PT Python is amazing and IPython is amazing. You know? It sounds like to quote an American commercial, 2 great tastes that would taste great together. Have you ever thought about talking to the to the IPython team and maybe building some of the the the the awesome PT Python interactive completion features into IPython core?
[00:24:16] Unknown:
Yeah. I I've indeed talked with, some of the IPython core developers, but, right now, that the integration is maybe, a bit idle. I we have both been busy, I think, with with other things. I've been busy lately much more at improving prompt toolkits and experimenting with Python and, looking for an even better architecture of prompt toolkits. So, the integration was maybe a bit on the pause, but, yeah, we will see. We will figure it out probably to to find a a better way.
[00:24:55] Unknown:
So, what are some of the most interesting uses that you've seen for prompt toolkit?
[00:25:02] Unknown:
Yeah. I I think Python itself probably was the the application where I really went to the limits. So that was the application where I really challenged the design. Otherwise, I think, like, the beaches CLI and and upcoming MySQL CLI will be really nice. And 1 1 other nice thing is, lately, a friend of me is developing a lot using asyncio and Python. And 1 thing for debugging an asyncio process, it's sometimes still hard to to debug an asyncio process because you don't want to have any blocking calls in it. So you don't want to have a REPL inside the async IO process because on everything else if if you're doing that.
And what he is doing, he is using an SSH server which runs inside the process, with lessons on a local socket. And he connects just, using message client to that socket to control and debug the the async IO process. And the thing he asked me was, isn't it possible to use the bt Python rebel and run that through the SSH server? And I'm going to have a look at that because I think that's really exciting if you have an SDK process and then you SSH to a local unique socket and you get a Python rebel to control another process, a Python process, which just goes on running.
So the rebel does not cause the process to to block. I think that's that's exciting.
[00:26:54] Unknown:
That is really exciting. Does your friend's project have a name? Is it is it something we can sort of watch out for?
[00:27:01] Unknown:
No. It's a commercial project that he's working on, but the SSH server is open source, and I will probably try to integrate with this SSH
[00:27:12] Unknown:
server. Well so, are there any other project we've obviously been talking about prompt toolkit and things like that and all the spin off projects. Are there any other projects that you're working on that you think might be interesting to our listeners?
[00:27:26] Unknown:
Maybe not necessarily interesting. But 1 thing I've been working on several years ago was a Python deployment framework. It is like fabric but a bit more advanced, but still not yet like SaltStack or Ansible or other Python frameworks that we have. And we use that to deploy quite a lot of Linux Ubuntu machines. But, I think maybe right now, Salt Lake could be a a better choice. And I I don't have the time anymore to
[00:28:05] Unknown:
to work a lot on that 1. Yeah. I do I do infrastructure as code work all day long, and I have to say, sometimes the community around the tool is actually more important than the tool itself. You know what I'm saying? Like, I mean, my current company uses Chef, and I happen to like Chef. And I think some of 1 of the things that makes Chef the most 1 of the things that makes Chef great in my mind anyway is the incredible ecosystem of of cookbooks and recipes that are around it. And I know the same thing is starting to happen with both Ansible and Salt. So, you know, sometimes, even if yours is better, it's like, it it probably makes sense to use the 1 that that that has the momentum in the industry.
[00:28:51] Unknown:
Yeah. Exactly. If if, you can write the best tool, but if if you don't have, the the people or the the knowledge to or the time to support all these people, you won't get anywhere. So it it's really important to to have a good community. And that's also why I'm now focusing more impromptu because I'm I really feel that that was a gap where we did not have a solution yet and which was something I liked. And so I prefer to to spend my time on that instead.
[00:29:27] Unknown:
Makes good sense. Are there any questions that you feel like we should have asked you but didn't? Something that you think that, you know, you'd that you'd like to tell us or tell our listeners?
[00:29:38] Unknown:
No. I I think you're doing a a great job, and, it's it's really nice to have a Python podcast. And, yeah, I look forward also to to the next interviews.
[00:29:51] Unknown:
Thank you. It's kinda funny that for for a long time, there were none. And then all of a sudden, we had this idea, and then, the other gentleman who does talk Python to me, he came out in the in the exact same week. So it's like we went from none to 2 in no time flat. But, thankfully, the Python community is huge, so there's there's plenty of room for both of us to thrive. So why don't we move on to the picks? This is where we have our guests as well as us go through things that we find interesting, neat, fun, tasty, whatever, things that we wanna recommend to our users or we think they might be interested in. So, Tobias, why don't you kick it off?
[00:30:29] Unknown:
Sure. So my first pick that I'm going to go with this week is a product called Vimcert, and this is a plugin for the Chrome browser that lets you basically use a Vim process or BIM style editor in any text input. So you click on a text input, hit control I, and it'll pop open an ACE editor with BIM key bindings so that you can then edit the entire contents of the text input. And then when you are done with it, you just hit colon w q just like in a VIM process and it is really useful. So I've actually been using it at work for managing some SQL queries that are being put in via a text input box, and it's much easier to do that than trying to manage it directly within the text input.
For my next pick, I'm gonna choose the Johnny Cash project, and this is a website that is a collaborative art piece and it is a music video of 1 of Johnny Cash's last recordings and people are encouraged to pick a given frame of that music video and draw it using a tool that they created. And then you can play the music video and it is a compilation of all the different frames that people have drawn, put together, and it is a really incredible experience. And you can actually choose different styles of artwork that people have done to view the video in different ways. So it's a continually evolving experience, and it's just really great fun.
My 3rd pick is going to be the movie Interstellar, And I watched that a couple weeks ago and it was really very well done, addresses a lot of interesting problems with how we're currently managing our natural resources and, you know, our ongoing discussion of space travel and colonization of remote worlds. And it also does a really good job of addressing the complications of relativity in space travel, particularly in how it relates to the main character's relationship with his children who he had to leave behind on Earth. So just really great movie, definitely worth a watch. And that's it for me this week.
[00:32:48] Unknown:
Great. Thanks, Tobias. This week, I'm gonna start off with a beer pick because I like beer, and I like really good craft beer. I just encountered a beer that is really unusual. It is called Grim Brewing's Telekinesis. It is a wild American ale. So I tend to be a draft beer snob. I don't often enjoy beer in bottles, at least when I can get away with it. I I tend to like to go to a pub and actually enjoy it right out of the keg. I just think it's a lot fresher and a lot tastier. And this beer came to me, and it looks like fizzy yellow limoncello. Cello. You know, like, for anybody who is familiar with that particular kind of lemon liqueur. So it's really interesting. It's kind of sour, kind of dry, not not sweet at all really or very very minimally so, just a little bit of hoppiness.
It's really interesting. I have to say, it's kind of in a category all its own. They call it a wild American ale. And, if you like beer and you're open minded, this is not, like, the kind of thing that if you drink Bud Light all the time, you're gonna appreciate. You have to be willing to sort of recognize that the beer world is is huge and varied, and and this is definitely something. This is an outlier. And and, thus, if you're a fan as I am, it's worth checking out. My next pick is this tool called Pandoc. It's an open source project and the idea is that it will convert documents of kind of any I shouldn't say any, of many many different formats to many, many other different kind of formats. And I started using it because, we do our show notes every week in Zoho Docs because which we previously picked because we can be collaborative about it, and we're literally the typing back and forth. But at the end, you know, we wanna transition the the picks and everything else and the questions we've asked to our our show notes website, and Zoho Docs will export a, Microsoft, you know, dot docx XML format document.
And then Pandoc will transform, transform it into markdown. So with a few minor edits, I can just put it right in the show notes site, which we run with Pelican. So it's a really handy tool. If you have a document of 1 format and you need it in another, I would definitely check it out, and the link's in the show notes. The next pick I have is 1 of those little tools that's kind of like you know, you you hear about it, you try it, you say, oh, I'll give this a shot, and then it it becomes kinda life changing. It's called Vimpager. And what this tool does is essentially, it replaces your your current pager, which is probably, like, more or less or whatever depending upon what you have configured and replaces it with VIM. And so the the really great thing about this is you don't realize how ubiquitous if you use Unix all the time, day in, day out, your pager is.
Things like looking at law like like looking at, source code control logs or reading man pages or reading long log files or whatever, and to have all the amazing text, you know, searching, manipulation, and etcetera features that VIM brings to bear. It's a really handy tool. My last pick is going to be a project another open source project called Homebrew Cask. This is for Max only, because the Homebrew package manager. But what's really cool is Homebrew Cask basically takes it to the next level. And as opposed to just open source project, which is mostly what homebrew itself is, these little packages that you can download easily, Homebrew CASK lets you install fully fledged commercial applications with Homebrew, like Chrome, like, you know, iTerm, like, various very your the all the web browsers, all the mail clients, all the apps that normally you would have to download, unpack a dot DMG file, which is the OSX specific application archive, and do the drag and drop thing with the icon.
And what's great about this from my perspective is, you know, I can write a little script. And so when I get a new machine or I walk onto a new machine, I can have it, you know, install all my applications that I want in in 1 fell swoop. So I I find it really handy. And that's it for me. Jonathan, do you have any picks for our audience?
[00:37:15] Unknown:
Actually, I forgot to choose any any picks, but I think, talking about beer, that was yours. 1st pick, I think. I think if you like beer, then you should certainly come someday to to Belgium.
[00:37:28] Unknown:
Oh, yes. Yes, indeed. I I am a huge Belgian beer fan, and I feel like I've just explored the very tip of the iceberg. I I I love Belgian beers. I I I love the kinda subtle fruitiness of them of of some of them and and the complexity, and they're just they're just great. It's not quite I'm actually I'm not sure if it's Belgian or not, but, Duchess de Bijon, that's 1 of my favorite beers of all time. And that's actually, that's I guess that's from the Burgundy region, which is not Belgium. Right? That's, like, France or something like that. I I mean, geography is really terrible.
[00:38:06] Unknown:
It it could be. I'm not entirely sure actually.
[00:38:09] Unknown:
So what are some of your favorite Belgian beers? What what what what if you if if, like, let's say our listeners get a chance to visit Belgium, what should they what should they not miss?
[00:38:19] Unknown:
I don't drink that much beer, but 1 of my favorite is probably Hushfoak. I would recommend that 1.
[00:38:27] Unknown:
Okay. That sounds great. So at some point, we'll have to get the spelling of that because I'm not sure that I will get it right on the show notes. So we can we can look it up and and and allow our listeners to, to find it. Is there anything else that you'd like to recommend? Any games that you play? Books you've read? Movies you watched? Anything?
[00:38:48] Unknown:
Good question. No. Lately, actually, I'm more like dancing a lot. We and and Belgium, we we have nice community of people doing folk dance, and that's what I like a lot. So that's more of my free time.
[00:39:03] Unknown:
No. That's fantastic, actually. So what kind of folk dancing? Morris dancing, contra dancing? Like, what is it Belgian folk dancing? Is there is there a particular a particular technique or or genre that that is germane to Belgium?
[00:39:19] Unknown:
It's, most the things we are doing is are mostly coming from Western Europe, and it's still improvisation. So it's not dancing for public and more for our own fun. And we have quite a lot of different dances. We have, couple dances. We have group dances. And most of them are originally from France, from, maybe a bit from Belgium, from Sweden, so Western Europe.
[00:39:47] Unknown:
That's great. Okay. Western European folk dancing. Sounds like fun.
[00:39:53] Unknown:
Okay. So, I think that'll do it for the picks. Tobias, go ahead. Alright. Well, Jonathan, thank you very much for joining us and taking the time to speak with us so that we could talk to you about your prompt toolkit and some of the other projects that you've been involved with. So for anybody who wants to follow you and keep up to date with what you're working on, what would be the best way to do that?
[00:40:15] Unknown:
I think maybe GitHub or maybe Twitter as well.
[00:40:19] Unknown:
Well, thank you again, and I hope you have a good evening.
[00:40:23] Unknown:
Yeah. You're very welcome. It was a pleasure.
Introduction and Host Information
Interview with Jonathan Slenders
Jonathan's Introduction to Python
Inspiration Behind Python Prompt Toolkit
Design Considerations for Prompt Toolkit
Projects Using Prompt Toolkit
Future of PyVim
Interesting Uses of Prompt Toolkit
Other Projects by Jonathan
Community and Support
Picks and Recommendations
Closing Remarks
