#336: Terminal magic with Rich and Textual Transcript
00:00 Have you heard of the package
00:01 Rich? This library allows you to create well.
00:04 Rich, terminal based UIs and Python.
00:06 When you think of what you can typically build with basic print statements, they may seem quite limited, but with Rich, imagine justified tables, progress bars, rendering of Markdown and way more. This is one of the fastest growing projects in the Python space these days, and the creator Will McGugan is here to give us the whole history and even a peak at the future of Rich and a followon library called Textual.
00:28 This is Talk Python.
00:30 to Me Episode 336, recorded October 13, 2021.
00:46 Welcome to Talk Python to Me.
00:48 A weekly podcast on Python.
00:50 This is your host, Michael Kennedy.
00:52 Follow me on Twitter where I'm @mkennedy and keep up with the show and listen to past episodes at 'talkpython.fm' and follow the show on Twitter via @talkpython.
01:01 We've started streaming most of our episodes live on YouTube, subscribe to our YouTube channel over at 'talkpython.fm/youtube' to get notified about upcoming shows and be part of that episode.
01:12 This episode is brought to you by 'Shortcut'.
01:15 Formerly known as 'Clubhouse.IO' and Us over at Talk Python training and the transcripts are brought to you by 'Assembly AI'.
01:23 Will, welcome to Talk Python to Me. Thank you. It's fantastic to finally have you on the show. I feel like we've talked a lot about the work that you've been doing many times, not so much on Talk Python because we're more focused on a single topic, but even so, I believe at the end always ask for some project that needs attention, need some sort of shout out. And I believe Rich has come up more than once. I think Textual has come up at least once there. So the prior guests of the show have been fans and I know the audience is a big fan, so congrats on all the progress there.
01:56 Great, thanks. And I appreciate the coverage. You probably increased my star counts by a few thousands.
02:02 Well, I do want to talk about that because this project is super popular and as we get into it, I think going to be fun to explore some of the things that you felt were key to that. And if this is the first time people are hearing about Rich, you definitely want to check out some of the screenshots. Maybe I'll do something fun, make part of the show, have the show notes or the podcast player have some screenshots from the various sections as I'll see if I can make that happen. But before we get to all that, before we dive into Rich and Textual and all the other things, let's talk about you. How do you get into programming and how do you find yourself doing all this open source Python?
02:37 How's it goin to programming? Okay, so as a kid in 80's, I guess I had a Spectrum 48K computer. It's a little plastic and you plugged into your TV, and you could create very simple animations and little games. And I think from there I was hooked.
02:53 That's just something about me that connected with them with programming.
02:57 I guess what's interesting is those games were so basic, right. They weren't like 3D, VR.
03:02 Oh, my gosh. I'm there or some of the Flashy, even the Flashy mobile apps, mobile games these days. But something about those early early games really captured the imagination, didn't they?
03:13 Yeah. And the fact that they were so limiting had to make you a little bit creative encourage creativity because you couldn't do much of anything. So you had to make the best of what you got. So I encourage you to experiment. And I think it was a great way to get people into programming again. I think until recently, we haven't had that. And I think the Raspberry Pi does that to some extent, which is a great thing.
03:35 I sort of reaches out into the real world in a more simplistic way, kind of repeating that cycle, right.
03:41 Yeah. And it just allows people access to programming, a very kind of accessible form for children. I guess so. I think the next generation in 20 years will be sighting Raspberry pi's. How do they go into programming?
03:55 Interesting. Yeah. I built a robot the first time around or something like that, right?
03:59 Instead of I wanted to play a game or script a game out or something like that. Interesting. And a lot of times I ask people, okay. Well, what are you doing now? They're head of data science that companies such and such. You've taken a very interesting. And I suspect a lot of people will be quite jealous of what you're up to these days. Right. What are you doing now? Yeah.
04:21 So up until recently, I was contracting and by ending my contract and I'm going to take a year out and, well, possibly a year depends how much. It depends how things go, but the ideas to work on open source, specifically Rich and Texture. There are other projects that take my fancy as well. Anything that I can contribute to might try my hand at it. It's not entirely selfless, because I do think there might be commercial applications for textural down the line, but certainly for this for six months, it'll be just focusing on just making it the best best.
04:57 Yeah super combination.
05:00 Absolutely. Well, I think I don't think it's gonna take that much to get some things in place to make this long term for you. People can go if their company or individually, they're finding huge value. They could go to GitHub and sponsor you.
05:14 There's enterprise stuff that can be set up. We'll dive a little bit into that more possibly later as well. But I wish you a lot of luck. But I think with the traction that you're getting and the new things like I really find GitHub sponsor feature to be something of a game changer. I remember looking back, you would see. Oh, here's a popular project. Maybe it's not even open source library, but it's like an app, and it's like click here to thank the developer on PayPal.
05:40 And there was a little bit of a barrier to entry.
05:43 Yeah. And maybe you do it once. Right. But with GitHub, you can say I just kind of want to say I want this to keep going. So here's $2 a month. And if not that many people who find it valuable send in a couple of bucks a month. All of a sudden it starts to be a foundation that you can really build from.
05:58 Yeah. It could build up and be something which is sustainable and sustain open source, because so many people benefit for open source, including big companies, big corporation. But a lot of these developers are doing doing it in their spare time for the love of it. And they haven't asked for funding before, but a lot of them deserve funding. Certainly. lots of projects which could really use funding to make sure they keep going to make sure that the software that we all use. It's still available in a year, two years and five years down the line. Yeah.
06:30 Yeah. Otherwise we're gonna end up in a place with, like, open SSL.
06:33 There's one person who maintains it in a quarter of the world seems to be built directly upon it. Right. Remember that bug it was a huge problem.
06:41 Heartbleed. Was it called which is a Heartbleed?
06:44 Yeah a heartbleed that's right.
06:45 Yeah. Which is a great name for a bug.
06:47 It really is. Why wasn't this fix? Well, there's one person who does it in his fair time, but everything depends on it. Yeah. But there's still one person who does it in their spare time, and it's just really hard to put that kind of energy and responsiveness into it. All right. Fantastic. So let's start with Textual, which I had on the screen. But let's start with Rich.
07:07 Rich is where things got started amongst Rich and Textual. Right. If I remember the history.
07:12 Yeah. Rich was about two years ago that I started out.
07:17 So tell people a lot of people have heard of Rich, but maybe tell folks out there, how would you describe it? We've had ways to sort of print stuff. Nicer. We've got pretty print Python. We've got colorama, where you can put color into your terminal, but this takes it to an absolutely new level. So tell us about Rich.
07:36 Yeah. That makes it difficult to describe sometimes when people ask me what it does because it does quite a lot of things, but it's all under the umbrella of writing more sophisticated output to the terminal. At the basic level, you can set colors, and you can set styles like bold, and italic the next level up.
07:54 It'll do word wrap, and it also word wrap the styles, so you can apply bold and then word wrap it. And then we have things like tables, this quite sophisticated table support, which are quite close to HTML tables include things in cells.
08:10 You've got a header row, you've got a little divider, and then you've got the data. Yeah.
08:14 And then you can draw lines around it and change the styles, and.
08:19 You can have alternating rows. So it kind of helps you line across, which is pretty neat.
08:26 Yeah it's quite sophisticated. It's all composable. So if I've got a table, I can obviously put text inside it, but I can put another table inside it. Or I could put a progress bar inside it or syntax highlighting inside it with ideas that rather than lots of separate libraries which don't work well together, which I think was a situation that we had previously. Now they all work together. They fit inside each other and they integrate quite well.
08:49 Right. So you could take your formatting and put it in your word wrap and put it inside of a table cell or something like that.
08:56 Yeah. So one of the things that struck me well, there's a couple of things, but one of them is just how popular Rich is.
09:03 It's almost 30000 GitHub stars that's close to Fast API level of popularity and not that far behind Flask and Django. That's really, really popular. When did you create this?
09:14 Two years ago. Yeah.
09:17 So I guess on the timeline similar age to Fast API, but much younger than Flask and Django. If I'm comparing into those and over here, it says on your page you have 2 million downloads a month. That's pretty incredible.
09:31 Yeah. That's pretty crazy. I think quite a few of those are automated from CI systems. Yeah.
09:37 But I do see that rising quite steadily. Yeah.
09:41 I wonder how many of the CI systems just in general out there do caching at some level where it wouldn't register. Right. If I pip install a thing I've already installed, and it's a certain version. And I'll just say using cached version versus if you create a brand new Docker image, and then the next thing you do is install your Pip, install your dependencies inside of your Docker container. That's a true download, right. Because that machine is totally fresh.
10:06 Yeah. So it's hard to tell.
10:08 I don't know. Do you have any feel for what that breakdown is?
10:11 To be honest, I'm not sure that site doesn't give you the breakdown. To be honest, what I would be interested in this is how many developers type pip install rich in that month, how many human beings played with it? That would interest me more.
10:25 But suffice to say, quite a lot of people use it. It's quite a lot I'm looking. Yeah.
10:31 I'm sure it's changed the way that you think about working on the library and whatnot right.
10:36 Maybe this might destabilize. This might cause a problem or this might cause confusion. It's one thing to do that for a thousand people. It's another to do that for 2 million. That's right.
10:48 You're gonna hear a lot about absolutely.
10:50 I didn't follow Semver very strictly originally. I always plan to use Semver and people are starting to use it. And I made a breaking change, and I didn't think anyone was using this particular feature, so I didn't increase the major version number. And then a couple of days later, I got an issue someone telling me off.
11:11 Quite rightly. So for not warning them about a break feature. So since then, I've been very, very strict.
11:18 It's a version ten.
11:19 And that's because I've made ten changes breaking changes to API. They're actually quite small. It might just be one signature and one method that requires a major version change.
11:31 Right. But at that scale, obviously, that if it affected at people, you're going to hear about it. And whatnot right.
11:37 Exactly. I don't want to break anyone's code. They don't want to give them a bad day. So I'm very strict about that kind of thing.
11:42 Yeah. Fantastic.
11:44 And also people should pin their versions. Right.
11:47 So on the flip side, they can also make sure that what they're working on is nice.
11:53 Stable, right.
11:54 Yeah. A lot of people don't. I do search GitHub sometimes for rich. And I look at their pipe tunnel. Was it that pipe project? yeah. And a lot of people don't pin their rich, fresh number. It'll just be rich.
12:08 And yeah, it shouldn't break too much. And often it's a hobby project. So it's not the biggest deal, right.
12:13 It really depends. Like it's one of the things I struggle with. So I do a lot of course development. Right.
12:19 I don't necessarily want to pin people to the oldest version. I'd rather let them have the newest stuff. So it exactly matches the documentation as they go check it these days and stuff. If they go back six months and watch the video or check out the demo app, but at the same time, there's a chance of that instability. There's always this tension. Right. I guess it depends on what the use case of that app or that library is.
12:42 It's tricky to say the last time critical is for your business or your project, the more you can relax if it's a tutorial, maybe it doesn't mark quite so much. But if it's some critical infrastructure right, then do you want to pin?
12:57 Yeah. For my web apps versions are pinned super strict. Even the dependencies of the Dependencies, like the transitive closure of the Dependencies, are all pinned on little demo apps and stuff. It's just wide open. So I think it depends out in the audience we have Hybotics says, Will, this looks really good to me. I'm looking at repo now, so not everyone has previously heard of Rich, which is awesome.
13:19 It's good to notice a few people left.
13:24 That's right. Yeah. I suspect there's actually a lot of people who haven't heard it before. Again, check out the screenshots, because if you think, oh, here's something that sort of enhances terminal output that completely undersells the level of what you've pulled off here. And that's only before we even talk about textual.
13:44 Let's talk about compatibility, because one of the things I find with these sort of nicer terminal output, things like works fantastic on POSIX systems. But you better not be on Windows or if you're a data scientist, you like Jupyter notebooks, you can forget about it. But if you really want to run this thing like. So what's the story? Where can I use this?
14:03 Just about everywhere. Linux, OS X, Windows and Jupyter that was started out. It was Linux OS X, because that is the easiest platform to develop. This kind of stuff for. Windows is a bit of a black sheep.
14:15 It didn't quite work as a Windows is getting better, though, right? I mean, when it was 'cmd.exe', it was like, oh, boy, this is really different. But the new Windows terminal, I'm really digging it. The new power shell, things like, oh, my Posh extensions. I can feel much more at home on Windows on the terminal than I used to.
14:33 Yeah. Yeah. So the new Windows terminal is much better. Rich doesn't have to do quite so many doesn't have to jump so many Hoops to get Windows support. In fact, it just runs kind of as is. They still support the older Windows terminal, which does have a few issues. It doesn't has to be limited colors.
14:53 That's brave.
14:54 But I guess maybe you want to, right. If you're gonna give the app to somebody, you can't really package up the terminal, they're gonna run it in. So you probably want the best possible experience on. To be honest, most people are still gonna be running cmd.exe, even if they shouldn't.
15:08 Yeah, exactly. Yeah. I mean, I could just tell them to install Windows Terminal, but that kind of goes against the ethos this library. I just wanted to work so that people don't have to think about what it runs on. Yeah.
15:19 Put a lot of work initially into Linux, Mac OS and Windows with good support for the new Windows terminal. Very limited support for the old command prompt. That's still pretty good.
15:31 That's still pretty good.
15:32 I think it's fantastic, actually. If people are really passionate about their terminal and they run Windows, they probably know about Windows Terminal anyway. So they're probably good.
15:40 The yeah.
15:41 The one that I thought was interesting and nice is Jupyter notebooks, but was the support there?
15:46 So it works quite well. So I wasn't a big Jupyter user at the time. I was obviously aware of it, but didn't use it myself.
15:55 And people ask me for Jupyter support. I thought it doesn't do that. It just works in the terminal. But then I looked into it.
16:02 And it wasn't too bad because I already had functionality to explore terminal content to HTML, so I could put a little wrapper around that, export it to HTML, and then insert it into a Jupiter that they've got an API, which allows you to write content into a notebook. And so I got Jupiter support up quite quickly, quite easily. And it works quite nicely, which people appreciate. It means that you can write code, which writes it's a terminal, mostly. If you do happen to run it in a Jupyter notebook.
16:32 Then it'll write the same thing here as well to know to text that it's running in the Jupiter environment, and then it just.
16:38 All right.
16:39 Output is not print output is generate HTML.
16:42 Exactly. Yeah, and Jupyter does have tough support for that. It will capture standard output and it will convert the colors and everything. But the problem is it wrapped the lines. So if you expanded the window, it would break any kind of neat formatting. If you've got, like, a grid or a table, it would break that. So I had to do the HTML export within rich as well.
17:03 Yeah, basically, most anywhere people do Python with a UI of some sort. This works is the takeaway. This portion of Talk Python to Me is brought to you by Shortcut.
17:16 Formerly known as 'Clubhouse.IO'. Happy with your project management tool. Most tools are either too simple for a growing engineering team to manage everything or way too complex for anyone to want to use them without constant prodding. Shortcut is different, though, because it's worse. No, wait, no, I mean it's better. Shortcut is project management built specifically for software teams. It's fast, intuitive, flexible, powerful, and many other nice positive adjectives. Key features include team based workflows. Individual teams can use default workflows or customize them to match the way they work. Org wide goals and roadmaps. The work in these workflows is automatically tied into larger company goals. It takes one click to move from a roadmap to a team's work to individual updates and back height version control integration.
18:03 Whether you use GitHub.
18:04 GitLab or Bitbucket Clubhouse ties directly into them so you can update progress from the command line keyboard friendly interface. The rest of Shortcut is just as friendly as their power bar, allowing you to do virtually anything without touching your mouse. Throw that thing in the trash. Iteration-planning, set weekly priorities, and let Shortcut run the schedule for you with accompanying burndown charts and other reporting. Give it a try over at 'talkpython.fm/shortcut' again that's 'talkpython.fm/shortcut'. Choose Shortcut because you shouldn't have to project manage your project management.
18:42 Just going back to the pinning version stuff. Waylone on the live says. pip compile specifically from pip Tools is a game changer for Pin Dependencies and pip compile specifically for managing Dependencies. That's what I've switched to as well. So I just run a script checks for all the new versions, regenerates all the pip compiled stuff, and I'm really enjoying that. I think that's fantastic.
19:01 Okay. use compile to check that.
19:03 All right. You basically define a requirements file that has what you actually would have pip typed pip install, and then it'll generate a requirements.TXT. That is the transitive closure of all of those dependencies which are pinned. And then you can ask any time for it to update the versions. The pin versions of that.
19:22 Okay. It's not like poetry's lock files.
19:25 I think it's similar. Yeah, I'm not 100% sure, but I think so. All right. So let's talk about various features here. I think just going through. I mean, we touched on them, but let's dive into it a little bit, maybe talk a little bit about the code. You right. So Kim Van Wyk is here to kick us off on the first one. Try something as simple as "from Rich import print" in your next project, and you'll be amazed.
19:48 So Will tell us why we'll be amazed. Like what's this alternate print.
19:52 When I first wrote this as a console class, you have to construct a class and it's got a print method. But I figured I could just overwrite the existing built in print because it's a function in Python 3. I can just replace it with my own version.
20:08 So that's what I've done here. There's a version of print we can import from Rich, which has the same signature as a built in print, but it supports the console markup, so you can insert these little square brackets with the style. Like here we've got Bold magenta, and it'll do emojis colon.
20:27 cool one's, and these styles, like the square bracket bold magenta/boldmatch. This is specific to Rich. This is something that you came up with.
20:36 Yeah, that's right. It's called I call it console markup, and the syntax is very BB code, like, I don't. If you were used,BB code. Yeah, it's quite simple. It's just like a markup where the tags of square brackets.
20:50 Yeah, I like this a lot, because one of the things that I use a lot still, which maybe I need to start to switch to. What you're doing here is Colorama.
20:59 But for Colorama, you'll do things like your import the foreground settings or styles, and then you can save foreground.green, plus the text.
21:10 Then. Foreground reset to go back to normal, but you don't have the bold, and then all of that stuff has to happen in code, right. If I wanted to say import some text and then show it on the screen, that text could have these styles in it. Right.
21:24 That's right. Yeah. So you can embed it in code easier or be different file etc and I think it's a bit easier to read rather than doing lots of string concatenations. And also the benefit over the colorama approach. Colorama is a very good about software. I've relied on it for years. But the problem is so when you concatenate strings like that, you insert these ANSI codes. Once you've built that string, you can't do anything with it. Really, you can't word wrap it. You can't format it. So with console markup, you can do you can Mark up bits of text with color and style, etcetera. And then you can further do operations on them, like word wrap and centering text and putting inside the table, etcetera.
22:03 Right. Two other things that jump out here that are interesting is you have emoji support, so you can say colon vampire colon, which is pretty awesome.
22:12 You can technically, if the file format supports that, you could actually put a vampire emoji in the string. It's still kind of nice that you have this sort of emoji lookup. Right.
22:23 Exactly. Because if you want to insert the Unicode character, you'd have to go and find it and then cut and paste it this way you can just do colon. You can set that into console markup. Just calling Colon vampire colon smiley on. I think there's a couple of thousand emojis you can use their fantastic.
22:39 Then another thing that jumps out is your printing. Hello, bold magenta world. So that's the word world bold and magenta, and then the vampire. But then you're also printing out a dictionary. And the dictionary is like pretty printed, but also syntax highlighted.
22:57 So if you print a container like a dictionary list or like an atomic Python type, it'll run the pretty printer over it so it will format. It kind of the style that people like in code. You probably format. This is how Black would format it. So it looks much the same.
23:15 Then it runs syntax highlighting over it. There's a few regular expressions in Rich. You can say anything between two quotes it is a string and therefore green. Anything in angular brackets is a tag like thing. So I'll bold the brackets and change the tag name to bright red to wherever is, and so that the output you can is quite readable and looks like something that came out of VS code or your editor. Yeah.
23:43 The more I look at this some more. I think maybe just every project I'm going to follow. Kim's advice and just from Rich import print, because why not? Right. This looks has all this cool auto formatting. Does it look actually at the type that it's printing to make any determination? Or does it just look and see if it's source code and then try to format it?
24:01 It looks at the time.
24:02 If it gets a dictionary or gets object versus getting like a true string.
24:07 It'll do both the syntax highlight a string, but if it's a container, if it knows that the type, it'll do some syntax highlighting there. There's also a simple protocol you can add to your own objects if you want them. Pretty print isn't formatted.
24:23 Okay, but not under stir Dunder wrapper, but something else under Rich.
24:28 It is Dunder Rich wrapper that you can specify the base arguments and parameters and the indentation. It'll render something that's very much like pretty printed date
24:38 That sounds like something that would be fantastic to add to some intermediate library that people use. So I'm sure I could create a class and add it to mine. But so often what I want to do is print out a Mongo engine model or a SQLalchemy or a Pydantic model. Pydantic could add that like these, like inter SQL alchemy, could add something like that. Oh, this is how you you describe like, this one has an index, and I think that'd be fantastic.
25:03 Yeah. So I've added to adders.
25:05 So it'll pretty print objects from the Atoms library. I have a PR for Pydantic as well.
25:11 So right in the future.
25:13 You print a Pydantic object and it will format. It quite similar to the built in data structures.
25:18 Yeah. Okay. Fantastic. I love it. So before we move on to this, I do want to talk about some other things because we're just scratching the surface here. But one of the things that I think is both impressed me and Brian and I over on Python Bytes on our podcast. We do there.
25:32 We've been continuously impressed at how fast you're adding new features and still kind of keeping the ethos of this library together. Maybe give people a little hint on just the velocity here How's that work?
25:44 Well, I'm not convinced that it's been that fast in bear mind riches.
25:48 It felt like a lot of work.
25:50 It didn't feel that fast it does but the thing is when I add new stuff to Rich. I'm not starting from scratch. There's several layers which are already built and well tested. The bit that I add might not be as large as maybe it looks.
26:04 I see. So you've already got a lot of structure and architecture that makes adding a new feature from scratch sort of thing. So a good design, basically.
26:12 I hope so. Yeah. And it seems to be working quite well because I did build a core feature set, and then I added some things to and admittedly, those things came quite fast because it wasn't that hard to implement. And I've got to a point now where Rich is quite large, I'd be resistant to adding any more stuff to it, unless it is very useful for a broad selection of users.
26:36 Sure. Do you have a sense of how many lines of code it is? I know you don't mean large in that sense. You mean large and sort of feature set. But do you have a sense of how many lines of code?
26:43 You know what? I've never checked.
26:44 I couldn't get at a time. We're done with this recording. Someone out in the audience will have already downloaded a check for who knows. All right. The next thing let's talk about is the REPL, so I can create a REPL Read Eval Print Loop by typing the word Python on the terminal and that opens it up. But it looks it's probably the least possibly good experiences you can have in Python, right. There's no color.
27:11 There's no feedback on sort of what's happening. Right. But then I could say from Rich import Pretty.install. And then all of a sudden, basically the output of the REPL. If I set a variable name, it will print it out. That becomes rich printed. Right.
27:29 That's right. Yeah.
27:30 So yeah. You call Pretty.install, and then everything you put into the after the prompt will be pretty printed. So previously, if you print a dict without Rich, it'll just smash it onto a few lines and it goes quite hard to are actually hard.
27:47 It's all one line except for the word wrapping, which doesn't even break on words. And there's zero color.
27:54 Exactly. So it's quite difficult to read. I'm quite a visual person. So I always had difficulty with this. If it was more than two lines, it'd be quite difficult for me to figure out where the keys and the values are. But if you do with Rich, it'll pretty print it on two lines and it'll indent it and like you would code and then it'll highlight it. So it makes things just much more readable. Yeah. A lot of people will put it in their startup files, so they just get this repl by default.
28:18 I'm interesting. Yeah. That's a good idea. Have you tried this on the more advanced REPL's like PT Python or BT Python or those where you kind of get an Emacs or Vim experience?
28:30 I haven't. No, I've tried it on IPython, and it works quite nicely on on IPython, but I haven't tried it on other.
28:36 Yeah. It probably was PT Python, but I haven't tried it.
28:40 Cool. All right.
28:41 Now another thing that you can do a lot with is sort of taken up to the next level. Is the console. Tell us about this. Yeah.
28:48 So the console class gives you more kind of advanced features. There's more options, more things to specify. And typically you'd have a single console pair project. You'd keep it in your top level object or as a global that has a print method. And there's also some of the methods, like there's a log method, and there's a whole bunch of features you can do when you construct the console things like exporting the output to HTML on.
29:17 Nice. That's fantastic. Yeah. So one of the things you can do with the console, for example, is you can set a style, say console.print and set some styles, and then it'll come out in that style, as opposed to embedding this console markup into the text itself. Right. Yeah.
29:32 So sometimes you might not want the console markup, especially if there's going to be square brackets in the output.
29:39 You don't want them to be confused with or even if you're receiving the string and you just need to put it on the screen. But you haven't generated the string or it was generated by some other part of the app. Here's a message I need to log this that I got. You don't to parse the string to try to put text into more text, right? Yeah.
29:57 Exactly. So you can disable the highlighting.
30:00 You can still set a style globally for that string if you want it in red or in whatever. You can still get that, but you can disable the console markup nice.
30:09 And then we have the inspect rich, inspect.
30:13 What is this one?
30:14 This is my favorite function in Rich, and it came quite late, but what it does is you call it with any object and it'll inspect that object and it'll pull out dock strings and it'll pull out methods, and then it'll render it a quite a nice little little table that it's quite easy to read.
30:36 And I find this terrific for exploring APIs. Sometimes it's better than documentation. If you get an object back from an API, you don't quite know what methods it supports. You just call Rich do inspect.
30:48 I could have Typed something like dir my print, my object, and I get a list of dictionary objects which are representing fields and methods and whatnot? but they're all jam together. There's no, like help. This is fantastic. So it's like almost a table version of that with one line of help. You do it right?
31:11 So it does the same kind of thing or help, but way nicer. Yeah.
31:16 It makes it easier, easier to eat.
31:17 There's also two things I see there's a block of stuff that has it's like a list of I guess there are field names, and then it has the methods. It's sort of called out separately as well. So you like these are the fields or properties. These are the fields. And then here's the probably methods and properties. Right.
31:33 That's right. Yeah. So it basically shows you the signature of all the methods and the first line of the Doc string. There's an option to show you the full details, but I find just that abbreviated information as generally as much as I need.
31:47 This is fantastic.
31:48 So it says things like copy equals def copy bracket bracket. Would it say async def if it was an async method or what's the alternative of def there is? It just a show. That's a method that just to show it's a method.
32:01 That's a good point about async. I don't think it does do async def, and that's a good idea.
32:05 It does'nt really hope to throw an async def or maybe a property if it's a getter method. Right.
32:10 You're right. Yeah. I think it probably should do that. I should inspect the method and see whether it's some async and then emphasize that. Yeah. That's a good idea.
32:19 Yeah, sure.
32:20 I'll open a PR on that podcast here no problem. Right. So those are ones that you've got graphics calling them out as some of the really main things. There's so much happening here that's amazing. But like, Waylon in the live stream points out, like, mention Rich trace backs. They're so good. I have my IPython automatically start up with that. And yeah, you've got a whole section down here under the library of things like logging log handlers, progress bars, status, treeviews, like tree reviews in the terminal that can expand and collapse with the mouse. There's more going on here than just the stuff we've touched on. Right. There's a bunch of cool features.
32:58 There's a lot going on here. Well, Rich will render. The tree view is textual, which provides the collapsing and navigation features. Yeah.
33:07 Got it. Okay. So we'll get to the interactive bits, but yeah. So I can still draw a tree view, even with your example here, you've got emoji icons for, say, folders and files. And then even in the file, you've got an embedded syntax highlighted a bit of code that comes out of one of the files in a markdown with some of the markdown rendered as a Rich markdown.
33:27 Just markdown not rich the library, but like, just colorized in formatting. Yeah.
33:32 So it goes back to the composability of Rich objects and my column renderable, but you can use them in various contexts. So in here you can set a renderable powered node on the tree so you can do what I've done here at a table next to a tree item or some syntax highlighting or render some Mark down.
33:52 It doesn't really matter to Rich what you ask it to render. You can just do in various contexts. Yeah.
33:58 Very cool.
33:59 So we've got the tree, which is amazing since Waylan mentioned. Let's talk trace back real quick. I mean, one of the things that really is tricky with the trace backs is a lot of times you've got to go to one end of them to see sort of the error. And then, like, there's no color.
34:15 There's just a lot of stuff dropping in there. Maybe sometimes it'll show the variable values, but not really gotta kind of pull them out. Things like that. And what you get here is ridiculous. First of all, what do I do to make this happen with a beautiful trace backs. You can do from Rich and Port trace back trace back to install. All good.
34:34 Yeah. And then if you don't handle exception.
34:37 It'll be printed with Rich or you can explicitly there's the second thing I gotta just put on all my apps.
34:43 Yeah, it's a piece of cake to add, so it's easy to do. Yeah.
34:47 So tell me what people who are not seeing this necessarily on the screen. What is this alternative trace back style look like here?
34:54 Okay. So it actually falls much the same format as a regular Python trace back. It's just underneath the file, you'll see some syntax highlighted code showing you that the line where the the exception happen for each frame and underneath each block of code, it'll show you the locals at that point in the frame so you can see the local variables. Right.
35:16 And these are called out in a nice table with a nice formatting that we've already talked about. So kind of as if you had done print from Rich import print and then printed out the locals into a table.
35:26 And it's all pretty printed, so it's quite easy to read.
35:30 I find with regular Python trace backs takes quite a bit of skill to read them, particularly for beginners and even for intermediates. You've got to sit down and analyze the trace parks, but I'm hoping that this just kind of presents the information in a more readable way and you can get more of the context of the error.
35:49 Yeah, I think this is fantastic. This definitely super interesting. I guess one more thing here to really dive into maybe two or two. I think the log handler is really neat, so people should check that out. But maybe tables. I know it doesn't sound as appealing and amazing as necessarily as what we've been talking about. But if I want to have a nice formatted table in a text output, I basically just don't do that. I'm like that is way too much work to worry about this, right. But with using Rich here, you can have almost HTML level formatting style borders on border off, just header content divider like alternating rows, like I said, a right, a line left align. There's all sorts of amazing stuff here. Tell us about the tables.
36:34 I didn't realize how hard tables would be to implement when I started it or might not have one done it. Tables are quite complicated because you've got to calculate optimal column width, and that gets really complicated when you've got text, which can wrap and other renderable that can go in those cells.
36:55 It does work quite nicely now, and it can handle just about anything you can throw at it, and it will scale the table nicely and elegantly if it doesn't fit into the you know, the width of the terminal, and it's also quite a good layout tool. You can switch the borders off entirely and then use it to lay out other things.
37:14 One thing that comes to mind right away is I think of some of the nice progress bar type things for the terminal, like TQDM and stuff, and they're great, but I'm always like the stuff on the right.
37:25 It'll have what it's doing and then it'll have a progress bar and then it'll have maybe how fast is it operating or how much time is it got to go or something? And those are always kind of like doing a little pulse in because the thing on the right is always changing and they don't never quite line up. You could do that here, but have a table and put the progress bar and one of the sitter fill bits right.
37:44 Yeah. So you can do lots of things regarding alignment for everything together. And like I said, to stop that effect where its content will flicker because they're using less characters because it goes from 100 to 99. And then yeah.
37:56 Yeah. Yeah. It's a very good layout tool and also just a good way of presenting tabular information, which is kind of what I would sign for.
38:04 Yeah. It is a table. Right.
38:06 All right. So last one, I've got some content, probably a most common way that it's in the lightweight format, but you want to turn it into something full featured in terms of text is marked down. Right. So for example, the Python Bytes website is almost entire. The vast majority of the content there is marked down talk python training all the stuff we've got the CMS we built in the back end. It's all marked down. Rich has marked on support, too. Right.
38:31 That's right. Yeah. There's a Markdown class. I'm basically took common Mark library, which parses the Mark done.
38:37 I substitute the bits, which we're generating HTML with something which generates Rich output. And it turns out there's a reasonable job of things like headers and does the style just fine. And there's also syntax highlighting. It'll actually call out to the syntax highlighting code. So if you've got a Python code block will actually highlight that Python code block. Yeah.
39:00 You support for inline code with the back tick thing. Back tick the blocks of code, which are the triple backslash or triple back ticks four spaces or whatever.
39:10 Yeah. So it supports much of the basic common Mark syntax and does a reasonable job of rendering. It won't look quite as good as a web browser. I find it quite readable.
39:20 But it's in the terminal, and it's in the term anything to get it there. Right. So that's pretty fantastic. Yeah. Really. Really nice.
39:28 All right. So I think this is probably as much of the details of Rich we want to dive into in terms of the feature set and stuff, but there's still more to go. There's a lot of love out of this library, which is great. Maybe just give us a sense of the internals. How did you make this happen? How do you make it work? It's just curses to the nth degree or what's happening.
39:50 There's no curses that there's a layer.
39:52 What makes most of it work where I render everything into. And that's a list of what called segments. A segment consists of a bit of text plus a style. And the thing about having that intermediate layer before you actually render to the terminal is you can manipulate it afterwards, so I can apply color and style and then do word wrapping, and then it can render it on to the terminal.
40:18 So everything is built on that and a protocol.
40:22 So objects can add a couple of methods. They can add a Dunder rich or Dunder rich console method, then they can themselves be renderable so you can print your own custom objects. And that will use the intermediate layer of segments to render everything onto the terminal. Nice.
40:38 Okay. Yeah. It sounds like a really good separation. And you could probably also, if you need to do something specific for one platform versus another, that layer you can make a decision on how to do that without that's.
40:49 Exactly it. Yeah.
40:49 Having to put it all over the place, right? Yeah.
40:52 So I render onto the segments and that's the platform independent. But there's another bit of code which will convert those segments onto the appropriate format of the platform.
41:02 And the platform might be the number of colors that's supported by terminals, because some will support 16.7 million colors. Some will support 256, and then some will support 16. Yeah. But because of that intermediate layer and I can make sure that no matter what you write, will work on the terminal and the given platform.
41:21 Fantastic. One of the things I do want to circle back to is this idea of you're taking a year off to continue to work on this project, to grow it even further, and it already has and also do other things in this general realm. And so there's a couple of ways which people can support you. Right. If you're a large bank, that depends on this kind of stuff. One of the good options is tied Lift. People get a Tide Lift subscription, for rich. And where do they get with that?
41:49 So I don't think you get a subscription for rich per se, but you can get a Tide Lift subscription. I see understand that means that money is divided amongst all the open source projects that you use that are signed up to to Tide Lift. In return, you get a more responsive developers and developers which will handle security issues, etcetera. Takes the risk out of open source code for big organizations because there's a little bit of risk if you're relying on someone's hobby project or are they going to be around in six months to a year of time?
42:23 So absolutely. Tide Lift ensures that developers will be around in the future to support your code going forward.
42:30 Absolutely. The other one is right up the top here. I could click Sponsor, and then I can come over here also, that pulls up a link to the external funding for Tide Lift, but I could hit sponsor. Do you have, like, plans or anything like that? I know some projects have there's like a gold sponsor here's. Just a sort of keep it going sponsor, do you have anything like that or is it just what people want to sponsor supports tiers.
42:56 Depending on how much you want to sponsor? I will help you with your projects.
43:00 I'm always happy to help people actually open source projects always happy to do that. But for the larger tiers, I will do code reviews, or I will help you with your project on a more formal basis. I might even write code for you. It's up to what you want to sponsor. If you just want to say thanks, that's very much appreciated. If I fixed a bug for you and just want to say thanks, then that's fantastic. But if you're a company which is benefiting from the work I do or the work that other open source developers do, you can sponsor a bit more, ensure that it keeps the work going right on.
43:35 Yeah. I encourage people if they're depending heavily upon this help you keep going strong, especially as you're transitioning to just working on this. Yeah. Also notice someone's forked it since we even pulled it up here.
43:47 How cool.
43:48 So the next step that maybe you would take this you talked about now wanting to add too many insane features to Rich to keep growing. That right. Keep it focused on target is you also have this project called Textual. Textual is a TUI. We've all heard of a GUI, but a TUI is a Text User Interface instead of a graphical user interface, right.
44:10 Yeah. I think it's a bit of a misnomer. I mean, because Interface has constructed the text of granted, but it's still a graphical thing you're looking at. Yeah, I think of it is a GUI, but with kind of like a really retro aesthetic.
44:22 Yeah. It does have a bit of a retro aesthetic. I would say maybe if you built something with colorama or something, that would be maybe more two esque. Right. Where you look at what you build with textual. It's got scroll bars, it's got banners, it's got icons.
44:38 It's closer by far.
44:41 Looks a bit more graphical.
44:43 Yeah. Yeah. So tell us about text role and why not just more features on Rich?
44:48 Rich has some kind of dynamic features.
44:50 There are progress bars, and they're updating live dashboards. And I've been asked quite a lot if I could add keyboard support and mouse support.
45:01 And I've resisted for quite a while because I want to keep the focus of Rich onto just generating mostly static output.
45:10 But then I saw a project called GH Top, which is it's kind of like HTop, but it would take information from the GitHub API, and it would show you like, real time events, and they used, oh, there we go and use a Rich for that. And when I saw that, I realize I've got to do this, there's a lot of potential there, and I put it off a little bit. But then I started on it and I kind of realized that. Yeah, there's quite a lot you can do with the terminal these days.
45:38 This is one of the things that blew my mind. Maybe give us a sense of I'm trying to pull a particular picture. And maybe this is just one I could sort of leave on the screen. But one of the things I remember from my early days of GUI type development is how do you resize stuff on the screen? Right. So I want to put something where the main windows here. But then I want the status bar thing, but I wanted to stick to the bottom and then I want some other stuff on the left. And it sounds like that would be pretty tricky to just dynamically try to generate with rich, but with Textual, you can say this thing docks to the left and this docks at the bottom. And here this fills the main content. And then those bits in the middle are those basically rendered either more of these containers in these widgets, or is that rich directly or give people a sense of what they build with this?
46:25 So rich does the rendering, which is responsible for getting stuff onto the screen. But Textual handles the dynamic stuff at the most atomic layer. There's something called a widget, and a widget is almost like a software component in itself. It's built on Async/io. So each widget has its own asyncIO task, and it's constantly processing event. Textual will change the size of that and change the layout in response to resizing the terminal.
46:55 And you can tell it how the the widgets fit together within the given dimensions of the terminal.
47:02 Right. So you've got the layout elements that handle docking.
47:08 Very cool. So one of the examples you have on the Textual read me is building one of these widgets. So you just create a class that drives from Widget here you have a Hover example and it has a way to render itself. And then it very much like traditional. I'm thinking of building like VB6 apps or Windows Forms apps like the traditional ones where you have drag and drop widgets. They have these events. Right. And one of the events here, you wouldn't think of this as a terminal thing. We've got like on enter on leave and mouse over and things like that. Right. Like those are regular UI types of interactions that you would not expect to see in a text base to have. Right?
47:53 That's fantastic.
47:54 It's based partially on my knowledge of writing desktop applications, which is quite old.
47:59 Now, where did you write them in WX widgets mostly. Yeah.
48:03 So CSS framework. I think it's got a Python layer. Yeah.
48:08 I use Python. I think that might be the next the Python wrapper.
48:13 That's right. Yeah. But in the last ten years, I haven't done any desktop applications have been working mostly in the web, so it's mostly influenced by web development with modern frameworks and particularly Vue, which I've used the times used.
48:26 Very nice. So I'm trying to replicate some of the best features I think of Vue into the terminal. I'm surprised how well, some of these features translate. Yeah.
48:36 This is incredible. It really does build these interactive things. And now another thing to talk about is how do you control the look and feel right? The way you might do in Rich is you might have one of these console markups or Mark down, or you could use a console in set of style.
48:50 But if you're inspired by the web like, dot main container hash thing, I want to style it like it some sort of CSS selector, right?
49:01 Yeah. So you've read my mind being last a few days working on CSS, it's going to work very much like.
49:08 Is it actual CSS or CSS? Like stuff like, what do you have in mind here?
49:12 It's probably not actual CSS. A lot of the stuff just wouldn't apply. Yeah. Terminal.
49:17 But essentially it's the selector. So I will have selectors where you can select an ID and then a child with a class name, etcetera.
49:26 I mean, that's basically what I was thinking. What I've seen real CSS, right? Is it where I say, well, I say, like, hash container, dot children type. And I would write that or is it like.
49:36 Not exactly that, but exactly like that.
49:39 The only thing that differs is the so column, the bit that goes inside the curly brackets, the actual rules. They will be different.
49:46 Sure. Yeah.
49:47 They render different things, but very much like CSS. If you come from the web, you see this, you'd be very much at home.
49:54 Nice. I could probably even use less and transpile that down to CSS and then put the odds. Yeah. Maybe. Who knows?
50:01 Yeah. Maybe I was thinking, should I just do CSS, which is hard enough in itself? Or should I try to implement Less or Sass or one of these things and. Well, I'm try CSS.
50:13 First of all, if you get it working with CSS, then you probably can get the less compiler to generate the right CSS out of it somehow.
50:47 I think exactly.
50:49 There was a time where front end development, which scene is kind of like the baby brother of real development.
50:56 You and your JQuery.
50:59 That's not true anymore. I don't think it's been true for a while. I think front end development requires just the same type of thinking is back end. You've got to organize all these different processes together and mental models. And it's actually more complicated because there's so much going on. There's so many little things you've got to remember.
51:34 Yeah. So I'm trying to take what I think the good things about front end development and apply them. It's a terminal and hopefully leave out the things which I don't like so much. Yeah.
51:46 That sounds great. So maybe for this one, I think what people should probably do is they should check out the examples, the examples from textual. They can clone the repo and just run these and super easy. There's also a way to see them, I guess, on the developer video log. Here are these. You doing these videos here?
52:04 That's me.
52:05 Just a short demo each.
52:08 Nice. This is my ad. Apparently getting now will not play that can go YouTube. All right.
52:16 So yeah. But people can go and check these out because I think seeing it in action is really what you need to appreciate textual.
52:23 And it can demonstrate the features which textual can do, which I don't see in other TUI frameworks. I'm thinking particular animation. Yeah.
52:33 I was just thinking, like the CSS easing functions and those types of animations. Yeah.
52:38 Yeah. I was surprised that how well that worked to is animating things at 60 frames a second, and it can go up to 120 frames per second. Terminals these days that they're built on the same technology as video games. They use the hardware accelerated graphics under the hood so they can actually render Terminal updates very, very quickly. I don't think people have taken advantage of that.
52:59 How long until someone reimplement Doom on rich or on texture?
53:04 I'm sure it's possible you could render it and then render onto text. I don't know how you do it, but various ways of rendering images. So in theory, you could put Doom in the middle of an act.
53:15 I would say start with really, really small fonts in a big terminal window, so you get higher resolution.
53:20 Yeah. But yeah, you got the color, you got the emojis way you could make it happen. Awesome. All right. Well, we're getting pretty short on time here. Well, anything else you want to sort of throw in about textural or even rich before we wrap it up just to say that I like getting feedback input.
53:38 So if you have any suggestions, jump onto textual discussion board or if you find any bugs, let me know or connect with me on Twitter. And I'm happy to talk about these things.
53:48 Yeah. Fantastic. Also want to give a shout out to you on your other projects real quick.
53:53 Great. Yeah. So this is a PyFilesystem. I'm working on that for well over ten years now.
53:57 I've handed it over to some very talented developers.
54:00 But essentially, the idea is that there's abstraction layer for file systems.
54:05 So the same code can write to your disk drive or an FTP server or a Zip file, and just all works exactly the same way I do.
54:15 You have cloud format support, like S3 and things like that.
54:19 Yeah. Exactly. Yeah. So there's S3 version, and there's a Google Cloud version, and there's dozens of other implementations.
54:26 Any database stuff. Can I treat a table as a directory or something like that?
54:31 I wouldn't be surprised if there is. I don't know of any off the top of my head, but some people have done some quite creative things where they've made something which is not a file system. It looks like file system.
54:42 Look at this DROPBOXFS as a file system.
54:47 That's pretty amazing. Here's the index of file systems. Let's see. We've got application data FTP in memory. Oh, that's pretty slick. So you can read and write files, like, say, for tests and not care or ten files. Maybe temp files would be fantastic, right?
55:01 Yeah. So you use it temp files. And like you said, for testing so you can write it into memory without bothering to write it onto your hard drive.
55:08 But multi file system so you could multiplex reads and writes. That's pretty cool.
55:13 Yeah. That's more. Remember correctly, you can layer several file systems so you could have one to write and then several to read. And depending on where the file is, it'll just make it appear like a single file system. Yeah.
55:26 A lot of neat stuff here. So people, we got a lot of file reading writing do they can check that out? Also, I want to give a quick shout out Paul Everett on the live stream out there. So Paul and you Dove inside in a more visual way into textual right. So I'll link to a live stream you all did over there together.
55:44 Great. Cool. Yeah. That was fun.
55:46 Awesome. All right. Well, I think that pretty much wraps it up.
55:51 So I'll give you the final two questions. And before we get out of here, though, well, if you're gonna write some Python code, what editor do you use these days?
55:59 I might use VS. Code use out for quite a while. Quite happy with it. But I do try other Editors from time to time.
56:06 Nice and then.
56:07 In addition to Pip, install Rich and Pip, install textual. Any other packages out there, you want to give a shout out to that? You think you use some eyeballs and some attention. Anything is impressed to you lately.
56:17 I'm drawing a blank.
56:17 There's so many it is hard to choose.
56:19 There's a project I saw can I mention, one that use us. Rich. It was quite cool, of course.
56:25 Is called the Object Explorer.
56:27 It's a terminal user interface, but it's not. I think it's OBJ Explorer, which is quite nice.
56:33 You could create an explore a Python object and you can navigate into it in a visual way and it will show you the the attributes, et cetera.
56:41 Oh, fantastic. Yeah, that sounds really fun. Is this for in memory Python objects or database objects or what is it in memory Python objects.
56:49 So I think it's like a debugging tool. It's a bit like Rich don't inspect, but it's more visual. Okay.
56:55 Yeah. Fantastic. We'll have to link to that one. Alright, Will, so thank you for being here. This has been really great. Congratulations on both of these projects and all the momentum you've gotten.
57:07 Thank you.
57:07 Final Call to Action people want to check out richer textual. Maybe you want to support you. Whatever else you want to give a final shout out for call to action before we call it a show.
57:17 Just connect with me on Twitter. My handle is @will Mcgugan say Hi. I'm happy to talk on Twitter right on.
57:25 Be sure to put the link in the show notes.
57:27 Thanks for being so well. Thank you. It's been great.
57:29 Bye bye bye.
57:30 This has been another episode of Talk Python to me.
57:33 Our guest on this episode was Will McGugan. It's been brought to you by Shortcut and Us over at Talk Python training and the transcripts were brought to you by Assembly AI.
57:42 Choose Shortcut, formerly 'Clubhouse.IO' for tracking all of your projects work because you shouldn't have to project manage your project management. Visit 'talkpython.fm/shortcut' Do you need a great automatic speechtotext API?
57:56 Get human level accuracy in just a few lines of code? Visit 'talkpython.fm/assemblyAI'. Want you level up your Python, we have one of the largest catalogs of Python video courses over at Talk Python.
58:07 Our content ranges from true beginners to deeply advanced topics like memory and async and best of all, there's not a subscription in sight. Check it out for yourself at 'training.talkpython.fm'.
58:18 Be sure to subscribe to the show. Open your favorite podcast app and search for Python. We should be right at the top. You can also find the itunes feed at /itunes, the Google Play feed at /Play and the Direct RSS feed at /RSS on Talk Python FM.
58:33 We're live streaming most of our recordings these days.
58:36 If you want to be part of the show and have your comments featured on the air, be sure to subscribe to our YouTube channel at 'talkpython.fm/youtube.
58:45 This is your host, Michael Kennedy. Thanks so much for listening. I really appreciate it. Now get out there and write some Python code.