In this episode, we welcome back Will McGugan, the creator of the wildly popular Rich Library and the founder of Textualize.
We'll dive into Will's latest article on algorithms for high-performance terminal apps
and explore how he's quietly revolutionizing what's possible in the terminal.
From smooth animations to dynamic widgets and full-fledged 2E, or should we say GUI, frameworks.
Whether you're looking to supercharge your command line tools or just curious about how Python
can push the limits of text-based UIs. You'll love hearing how Will's taking a modern,
web-inspired approach to old-school terminals. This is Talk Python to Me,
episode 498, recorded February 4th, 2025.
Are you ready for your
host,
please?
You're listening to Michael Kennedy on Talk Python to Me.
Live from Portland, Oregon, and this segment was made with Python.
Welcome to Talk Python to Me, a weekly podcast on Python. This is your host, Michael Kennedy.
Follow me on Mastodon, where I'm @mkennedy, and follow the podcast using @talkpython,
both accounts over at fosstodon.org, and keep up with the show and listen to over nine years of
episodes at talkpython.fm.
If
you want to be part of our live episodes, you can find the live streams
over on YouTube. Subscribe to our YouTube channel over at talkpython.fm/youtube and get
notified about upcoming shows. This episode is sponsored by Posit Connect from the makers of
Shiny. Publish, share, and deploy all of your data projects that you're creating using Python.
Streamlit, Dash, Shiny, Bokeh, FastAPI, Flask, Quarto, Reports, Dashboards, and APIs.
Posit Connect supports all of them. Try Posit Connect for free by going to talkpython.fm
slash posit, P-O-S-I-T. Will, welcome back to Talk Python To Me. It's great to talk with you.
Thank you. It's good to be here again.
It's going to be really fun.
You know, I've built some really cool apps with Rich,
and we're going to talk about Rich and Textual.
Probably a little more on the Textual side this time around,
but still a very, very cool revolution you're bringing to the terminal.
Yeah, a very quiet but pretty revolution.
I like it.
Indeed.
Okay, so we want to talk about Textual.
You wrote a cool article called Algorithms for High-Performance Terminal Apps,
which I thought would be fun to dive in,
but we're going to also keep it more of a broad-ranging conversation.
At the start of all that, you know,
it's been a little while since I've had you on the show.
Again, tell people who maybe haven't listened to that episode
or episodes
who
you are.
Sure. My name is Wilmer Guggen.
I'm a software developer, Python developer,
probably like most of your listeners.
I achieved a certain amount of infamy
when I built this library called Rich,
which a lot of people use.
If you see some fancy output in a terminal,
that might have been me.
And I founded a startup called Textualize,
which is all about improving the developer experience
in the terminal.
And I'm sure we'll discuss Textual,
which is my other Python library in this show.
Yeah, absolutely.
I'm super excited for it.
And is this close to the one-year anniversary for Textual?
It was an anniversary of some sort
because we're going to talk about one of your,
one of your articles.
It's actually
closer to three years
since I founded Textualize.
Oh, no, you know, it's not,
it's the 1.0 miles.
Oh, right, yeah.
1.0 year, the 1.0 version.
There we go.
That's what I was thinking.
Yeah, so Textual follows Semver,
which I imagine people are familiar with.
When you're on the zero version,
you have a bit of flexibility
and you can make breaking changes.
We try not to,
but you can make breaking changes
and it gives you a bit of freedom
early on to play around with things.
But some people stick to
zero ver just forever,
which is fine if that's what you do.
But when you go to 1.0,
it advertises to people that this is stable.
You can rely on the interface
not changing too quickly.
And if there are any changes,
it's well documented.
If you followed along,
it's a very modest release
from the last zero version
to the 1.0 version.
But it says to the world,
hey, everything textualized is ready.
You can start using it in production,
even though you could probably have been using it in production for a year.
I'm sure that you
could have.
I'm sure you could have.
Are you familiar with zerover.org,
the numeral zerover.org?
Have you seen this?
No, I didn't.
I thought it was just an aspect of Semver.
I didn't realize it was.
It is absolutely an aspect of Semver.
But this, I can't remember who put this together.
Does it say at the bottom?
Let's see about the About page.
published yeah that's what i thought i thought it was mamoud hashemi amazing yeah so mamoud put
this together and basically it calls out
i
think it's it's a little contrarian to you know there's
a lot of especially larger companies that have rules about what version you're allowed to use
and is software ready enough if it's a 0.3 we can't use it it's not ready not until it's a 1.0 or a 2.0
or something along those lines, right?
And so this is
the
popular projects
that are still really, really low in their versions.
It says, welcome December 0.0.1.
And if you go down here, it says, like, look, React Native is 0.78.
Right, right, yeah.
Even though
it's 10 years old.
Hugo, which I use for my blog and love it,
it's got 77,000 GitHub stars.
It was first released 12 years ago.
More than a decade long.
It's still zero dot something.
Let's see if there's some that are really extreme here.
I think the problem is that
non
-software developers
have a different idea of what versions mean.
We
know that they're about compatibility.
But when you're marketing it, 1.0 is like you advertise it,
you make a splash about it.
That's when it's actually
out.
You can use it.
Otherwise, it's just like a toy, right?
And then, boom, 2.0.
Yeah.
Yeah, let's see.
NeoVim, 0.10.
scikit-learn, it's 15 years old, it's 0.17.
So I think I totally hear what you're saying, right, about like, yes, this, and I think we both agree, like, what this should mean.
If your thing is 0.17, probably that means there's a good chance that there might be some adaptations to the API.
at the same time if you're scikit-learn and you've had you've been around for 15 years yeah it might
be time to bump that to something over 0.17 you know what i mean
what
do you think it's
i
think it's
it's the um developer-led projects the ones which are just a bunch of developers releasing
at open source uh we developers don't like to make too much promises exactly if we were to put a 1.0
on it who's
going to be on the hook for making that 1.0 and then they're stuck with it right
Exactly. We know that 1.0 is not going to be perfect and bug-free.
So we don't necessarily want to be on the hook for it not being perfect.
Yeah, I know. At the same time, you're on the hook to not change scikit-learn at this point anyway.
You know what I mean?
And I'm only picking on them because I know they're so well-loved in the community and they're very, very common.
Unlike, say, Ruff, which is on this list, but Ruff is pretty new.
Anyway, I think I'll put this in the show notes.
Zero over.
Thanks, Mommy.
That was really fun.
So let's talk about terminals.
Terminal revolution.
I think it's a pretty interesting time for terminals,
both the application that runs your terminal
as well as closer to what you're doing,
building applications that are like CLI apps or 2E apps,
as we'll coin the term.
No, you've coined the term.
We'll tell people about the term if they don't know, right?
I mean, we've got Warp, we've got Ghostity,
I don't know how you say, Ghostity, whatever.
A bunch of other options coming along for terminals
that make being in the terminal nicer.
And I think also draw people into wanting to build apps
that run in that space rather than try to get away from it, right?
It's not macOS where it's just the default Z shell
with no history and it's like white with weird fonts
or CMD on Windows where you're like,
what is this thing, you know?
What are your thoughts on this?
I mean, first of all, like maybe just on the apps that run,
do you have a favorite terminal app that you run?
I've been using iTerm for the last few years.
It's kind of my daily driver.
But there's a few other good ones.
There's Alacrity and Kitty and then Ghost TTY or Ghost T.
I'm not sure.
That's a new kid on the block.
And it is very good.
It is very good indeed.
but I like I terms feature set
it's not the fastest but it's fairly reliable
and it's got lots of other features
I played around with
I
played around with
warp.dev as well
I think that's a little too
unconventional
for me at the moment
they've done some very cool stuff though
there's lots of innovation there
it takes some good news to you, that's the one I've been using
last year or so and I really
enjoyed it, it does some very cool things like
For example, if I'm on my computer and then I SSH into another computer and then in that computer I Docker exec something into a Docker
system,
a Docker container, Warp will say, would you like to apply the Warp shell to this Docker container instead of whatever does it?
It might not even have Bash, right?
It might just be SH.
You just hit a button and it goes, whoop.
It adapts and basically become kind of like in memory, installs itself into that container temporarily, right?
that sets all the
settings
and stuff.
So it's a long ways from cmd.exe.
I guess it's worth pointing out to people out there on Windows,
if you're not using Windows Terminal, please,
right?
You need to use Windows Terminal.
It's such an improvement over...
Massive improvement.
I mean,
you probably run into this all the time, right?
Yeah, and the solution,
if someone tries something in the terminal
they use is retro textual and it doesn't work properly,
I first say, we try downloading Windows Terminal.
And 99% of the time, it not only fixes it,
but it makes it look beautiful.
I mean, hat's off to Microsoft.
They didn't change the terminal for decades.
But when they did, they made a very good job of it.
Yeah, it took a while.
I don't know if it's the default yet.
You know what I mean?
I'm not sure what's actually presented
if you kind of pull up the start menu.
It's a very strange architecture.
You can pull up cmd.exe.
That's what I've been used to calling it
because it has it in the title bar.
If you send it some magic codes,
you can switch it into essentially Windows Terminal.
It'll process escape sequences like it does on Mac and Linux.
So the actual window you see is just kind of like a window
onto the thing which renders the terminal.
So you can get Windows.
You might already have Windows Terminal
even if you don't get the experience.
But software can switch it into this mode,
which makes it work really well.
I had no idea. That's cool.
Okay.
Yeah, it's probably the same core for both of them or something, right?
Yeah, exactly.
The architecture is very component-based
and you can switch it at runtime.
Yeah, that sounds very Microsoft.
Is there a code that you can put to embed?
Like if you can split the panes
and then you can embed Excel on one side maybe
and then SharePoint on the other?
I haven't found it.
I'm just kidding.
I wouldn't be
surprised, yeah.
I wouldn't either.
Are you a fan of modifying your shell, I guess?
You know, like, oh, my ZSH or
oh, my Posh or Starship or any of these?
Yeah, to change the prompt.
Yeah, I do have, I can't remember which one I use now.
It's not, is it Starship?
Yeah.
Yeah, it's fairly minimal.
It tells me the branch, the Git branch I'm working on,
the version of Python that's running,
and the version of the application I'm working on.
So that's really nice.
Oh, it'll tell you the version of the application you're working on?
Yeah, it says v1.0.0,
so it's somehow pulled out the version from Textile, I guess.
Oh,
wow. That's pretty cool.
I guess if it's in a repo and knows that repo is a package,
it can figure out what version it is, but that's still pretty neat.
I guess. I must go on the spec.
PyProject.toml, I'm guessing.
Yeah.
Yeah, I don't know. It's magic.
and it works.
So don't delve too deeply.
Yeah, the whole reason I'm bringing this up,
it might feel like a little bit of a diversion,
but when people think about terminal apps
and just being in the terminal
and somebody says,
oh God, I hate the terminal.
It's so bad.
I can't stand it.
It usually means they're not adopting
some of these really magical tools.
Regardless of which one,
regardless of whether you adopt Starship
or Oh My ZSH or Warp or whatever,
you get a dramatically different experience, right?
Yeah, it's infinitely customizable,
the terminal and the shell and various other software.
So you can get the kind of experience that you want out of a terminal.
People get very comfortable with their terminal environment.
It feels like an old pair of shoes.
It's just that comfortable.
I guess it depends what tools you use as well.
For example, if you're a NeoVim or an Emacs type person,
you're in the terminal even way, way more than, say, for me, for example,
use ByCharm and other tools that I only dip in and out
when I'm working on code for that kind of stuff.
Yeah, for me, I'm switching between terminal and VS Code most of the day.
So
I've got both
open.
I write some code and I switch back to terminal and run said code.
So I'm in both.
Yeah, but funnily enough, I never got into editors that run inside the terminal.
I do like all the fancy graphics that VS Code can give you that terminal couldn't.
Yeah.
That matters less to other people, but I like it.
You know what?
When I started out doing programming, I started out doing a lot of work on silicon graphics,
mainframes, doing Emacs on Onyx workstations and stuff like that.
And I was happy as a clam to get out of there as quick as possible.
get out of. I'm like, can I get some better tools than this? And yeah, I don't know. I'm on the GUI
side as well, but I feel like kind of like the terminal. If you don't customize your terminal,
it's not a great experience. If you don't really commit to learning all the hotkeys of your GUI app,
well, it feels like, well, I got to use this mouse. It's all clunky, but like I almost never
use the mouse. You know what I mean? Even though I'm in a GUI app, right? They just customize the
keys? I
think you can get very
proficient in both.
You know, I've seen people using a terminal and they
use Emacs or Vim
and their fingers just fly
through it and they're very proficient.
But the same thing in VS Code.
If you know your editor
and you know the shortcut keys and you don't reach
for the mouse very often, you can be just
as proficient, really.
At Textualize, we had a policy if you use whatever
you want to use to
edit
code. If you take a developer
who uses Vim
and then force
them to use code,
they will not be happy.
And they will not be as
efficient
at
all.
Yeah, that's a really tricky balance, right?
You want to let people work where they're comfortable, for sure.
This portion of Talk Python to Me
is brought to you by the folks at Posit.
Posit has made a huge investment
in the Python community lately.
Known originally for RStudio,
they've been building out a suite of tools
and services for Team Python.
Over the past few years,
we've all learned some pretty scary terms.
Hypersquatting, supply chain attack, obfuscated code, and more.
These all orbit around the idea that when you install Python packages,
you're effectively running arbitrary code off the internet on your dev machine,
and usually even on your servers.
But thought alone makes me shudder,
and this doesn't even touch the reproducibility issues surrounding external packages.
But there are tools to help.
Posit Package Manager can solve both problems for you.
Think of Posit Package Manager as your personal package concierge.
You use it to build your own package repositories within your firewall that keep your project safe.
You can upload your own internal packages to share or import packages directly from PyPI.
Your team members can install from these repos in normal ways using tools like PIP, Poetry, and UV.
Posit Package Manager can help you manage updates, ensuring you're using the latest, most secure versions of your packages.
but it also takes point-in-time snapshots of your repos,
which you can use to rerun your code reproducibly in the future.
Posit Package Manager reports on packages with known CVEs
and other vulnerabilities so you can keep ahead of threats.
And if you need the highest level of security,
you can even run Posit Package Manager in air-gapped environments.
If you work on a data science team where security matters,
you owe it to you and your org to check out Posit Package Manager.
visit talkpython.fm/ppm today and get a three-month free trial to see if it's a good fit
that's talkpython.fm/ppm the link is in your podcast player show notes thank you deposit
for supporting the show
all
right well i think that's a good transition to tui what is what are
tuis why do people build them i know we talked about this in the last episode we won't totally
necessarily rehash it but there are some people haven't seen it there are some incredible
applications and we will see some built in textual that run in the terminal yeah
sure so 2e stands
for text user interface um i don't actually like that term anymore okay um and the reason is well
the thing is um the 2e's that you build with textual are also guis um it's a very simplified
form of graphics but we've got we've got lines um and and corners and you've got like a mouse that
can move around. So it is rounded with text, but
it works just like a GUI. I guess it's a little bit like
saying a web browser is a document-based UI.
It's technically correct, but no. We're having this whole video
live stream recording across the internet,
across the world in a web browser, and there's only a little text on the
screen, right?
Yeah, exactly. So the term 2 is stuck, but
It's a GUI that runs in your terminal.
Well, I think originally it was pretty text-based.
It was.
The advanced version might be a progress bar, right?
Or emojis or color.
Yeah,
exactly.
So those are technically text, but it looks like images.
So you've got emoji.
You can have lots of, like, I'm looking at my Starship prompt,
and it's got a little snake because it's in Python and that kind of stuff.
That is technically text, but it is graphical.
and progress bars.
You create a bar using characters,
but essentially you're creating an image.
So I think the distinction between
text
user interface
and graphical user interface is fuzzy now.
If you say Tui, I'll know what you're talking about,
but I just don't like the term.
I don't think it's as clear.
I'm not sure we even need the distinction.
Yeah, I hear you.
Are you familiar with Vtop?
Have you seen this app?
Yeah, that's really, really pretty.
I like the fading effect.
I mean, this app has just crazy amounts of graphics
and it's all written in the terminal with live updating.
I don't know how many graphs, but many, many graphs.
Interesting thing about Btop,
I think most people who run it don't run it
because they really need to keep an eye
on the performance of their course and file system, etc.
I think a lot of them run it because it's retro cool.
It's retro cool.
It looks cool.
It looks like how you thought computers were going to look.
I'm going to be
a programmer and a hacker.
I'm going to be a super tech guy.
This, yeah, you know what?
It could be, this could be a movie UI.
You know how when you're watching a movie,
they're like, they fucked for whatever reason,
won't run macOS or Windows.
They come up with some weird variation that's got weird graphics.
Yeah, and have some dialogue
like,
I've got to hack the Gibson.
Okay, done.
Exactly.
I need to fill up something computer.
This is Visual Basic.
I know Visual Basic.
I know this, yeah.
I'm going to get his IP address.
It's like, what?
Yeah.
I don't know.
Oh, boy.
Anyway, I think this is a really, really cool example of pushing way, way, way beyond.
This is a graphical user interface.
This is not a textual user interface, right?
Exactly.
I mean, technically it is text, but it's also graphical.
Yeah.
So we have two things that you guys make.
We've got textual and rich.
And maybe it's worth talking about Rich for a moment
since that's the foundation.
Sure.
Okay, so Rich basically formats data
in a very pleasing-to-the-eye way.
You can print, say, a Python dict,
and it'll format with an indentation.
It'll colorize strings and things.
And you can print things like tables quite effortlessly,
syntax-highlighted code,
and you can use up to 16.7 million colors.
Essentially, it was a toolkit to prettify terminal output
with as little effort as possible.
And it's all kind of
integrated.
So you can put syntax-halled text inside a table
or a progress bar inside a cell.
And everything kind of works together.
So it's a single coherent system.
Because some of this stuff existed prior to Rich.
But they were written by different authors.
And they weren't designed to work together.
Maybe there's a
table
one by one person
and then a progress bar by another,
and they didn't really work the same or integrate
or things like that, yeah?
Exactly, exactly.
So it meant that terminal output was still quite basic.
When color was used, it would colorize a single line
or something like that.
And it still,
it
helped,
but it wasn't great for parsing,
visually parsing that information.
but Rich gave you that ability
that when you write output
it is readable
I think prior to that we developers
kind of built up this skill
of staring at monochrome
text with funny characters
and numbers and somehow
pulling out meaningful information
out of that and it took years to
develop
but hopefully now we don't need to
because you can write things to the terminal
that looks much like the output
you'd get in a browser.
It's formatted and readable and colorful.
Yeah.
You know, one thing that might be worth talking about
is the live updates, like live tables and stuff.
Yes.
So in Ritchie can create a live object.
That's what the class is called.
And basically it clears the screen
and it writes that output
and then you can refresh it.
It can do that quickly,
like 20 times a second or less,
depending on how much data you've got.
So you can create animations, you can create dashboards,
you can create like
a
scrolling list of text.
But it was kind of, it was limited.
Because all it could do is update information regularly.
It wasn't interactive.
You couldn't click or scroll or even detect key presses.
It was purely for updating information.
It's kind of like a very rudimentary predecessor
textual.
Another thing that's interesting is what's the frame rate?
of a terminal.
People think of it just kind of scrolling text
and printing out text, and you see it kind of going by,
and you're like, well, that's kind of how the UIs must be.
But you can actually push these things pretty far, right?
You can.
The interesting thing is I don't think anyone
who sat down to develop a terminal
was thinking in terms of frames per second.
They were just, they want to optimize the text output
So that if you cut a large file, it didn't take forever to scroll through.
Right, or didn't flicker around or something, yeah.
Yeah, yeah.
And later on, people like myself and others were creating animations and things.
And they're thinking, well, how fast can I push this?
And it turns out pretty fast.
Because terminals use your GPU to render the text.
And if you send a text fast enough, it'll keep up, mostly.
And I found that 60 frames a second is completely workable
on
most terminals.
You don't really need that for most apps
because if you're scrolling text, you can only move character at a time.
It's not pictal perfect because it's kind of like a grid.
So if you want to scroll at 60 frames a second,
you'd have to move 60 lines in a second,
with which text would just kind of
whiz by.
Yeah, it gets blurry
anyway.
Yeah, so it can do 60 frames a second,
which is sometimes fun for animation effects,
but generally you don't need it.
You can update 10 frames a second,
and it'll look nice and smooth.
But it's nice to know that you can.
We've got a ridiculous demo,
which creates a really colorful gradient
and then rotates it at 60 frames a second.
Wow.
It looks very cool.
It would be terrible in an actual app
because it'd
just burn your retina,
but it is possible.
Yeah.
Reminds me of the early days when computers just started having VGA and stuff
and people would come out with amazing
graphical,
what do they call them?
I can't remember what they call them.
Demos and things?
I think I was thinking demos as well.
Yeah, I think that is what they call them.
And we would download them off of BBSs and watch them.
We're just like, wow, it's so good on my 486DX.
I can't believe it could do it.
It's so smooth.
They were amazing, right?
Similar deal with the
terminals.
The manufacturer of those devices back then probably didn't have graphical animations or games in mind when they were building
those
computers.
But then you got some interested parties who were willing to experiment and they actually managed to
make
it do things, which the manufacturer just never intended.
The same thing with the terminal.
No one ever sat down and created a system to display 16.7 million colors at 60 frames a second.
It was other people that just tried that and got it to work.
So there's an amazing amount of creativity and freedom in working and stuff like that,
which I kind of missed from the old days because now computers are so fast and so powerful.
I know.
People don't have to even worry about it, do they?
I want to kind of work through this.
You have this live demo, the official textual demo, which you can still...
Let me go.
I think I have it in the next...
No.
If I click on it,
it
tells me how to get it.
props for the install step here, the UVX.
Are you a UV convert?
Are you a UV fan these days?
I am a fan.
Yeah, I mean, that I think is a killer app
that you can send someone a fairly short command line
and they can run your project.
The Python, it says --Python D.12.
That was because at the time,
it wouldn't install a version of Python that it can run on.
I think Astro's working on that.
So I think in the future, maybe now,
you could just do UVX text-demo,
and then it would just run.
But even so, I think that's a beautiful way
of allowing people to test your code
with very little barriers.
Yeah,
especially the script stuff now.
You can just use the script and
put the dependencies
at the top and just say UV run.
I can't remember the exact syntax,
but basically you can embed what it needs to run
just as a comment and it'll run.
That's excellent.
It's no harder than it needs to be,
which is great.
It's very clear what it does
and it works very well.
It's the kind of computing that you want.
You don't want to have to send someone
a page of instructions
and say, go and download this software
and then write this into your configuration file.
Yeah, that's just a headache.
I don't want to deal with that ever again.
I just want to send people what UVX, blah, and then done.
I agree.
If you have UVX,
you're good to go, right?
and you don't even have to have Python
and you also don't have to worry about the version of Python.
So these are all good things.
So let's run it and let's see what happens here.
There's a lot going on in this demo.
Chris May out in the audience gives you props
for making it so easy to run.
And Hugo says, I can drop, I can drop the Python.
As you imagined, I can just say UVX textual demo
and I'll probably get 13.1.
Let's see, something's happening.
I think it worked if you had that version of Python.
But if you didn't have the correct version of Python, it would sometimes fail.
Got it.
Maybe they fixed it.
Yeah.
Maybe.
So when this thing pulls up, it looks very much like a web browser.
With the main difference, I think, that there's not a lot of pictures, as in true graphics, right?
But if you imagine like a really nicely styled website that maybe used color and emoji and CSS, but just white on graphics, right?
I feel like, would you say that's kind of the extent?
It is.
It's kind of like a minimal web interface that focuses on typography.
That's not a potential because you've only got one
font.
Yeah, yeah, yeah.
Exactly, you can't.
Yeah.
But as we'll see, you can actually do graphics pretty well.
Yeah, if you see the numbers up at the top,
there's nothing in the terminal that's placed.
Most people are saying they won't know,
but at the top it says version, then it says 100,
GitHub stars 27.2 thousand
how many forks and so on
but those are colored differently
they look different
okay now tell us about the numbers
yeah sure so they're taller
and wider than the rest of the text
but there is no alternative font
in the terminal
those numbers are made up of other characters
box drawing characters
so you've got like a vertical line
a horizontal line
you've got a curved corner
you've got like a T section
and you can assemble that
and make it display something that looks like numbers.
It does look like numbers.
You've got the
little subscript for the thousands,
the kilo
stars, I don't know.
If I remember correctly, it's a two by three,
no, sorry, three by three grid of characters.
And I had to hand edit this in Python
by cut and pasting the box characters from Wikipedia
to assemble numbers.
And I discovered the numbers work quite well.
numbers look like numbers and i've also got hex digits so a b c d e f
um
i tried to keep going
but i found that some characters didn't work at all um like an x there's no diagonal cross piece
in these uh unicode characters so it's an x just became impossible with a three by three grid um
but for numbers it works beautifully yeah yeah very interesting a
little bit like a classical
alarm clock where the numbers
like a seven digit display.
Yes, exactly.
Yeah.
Cool.
All right.
So if you run the demo,
it comes up with comments
that show you or sort of a
walkthrough of what's possible
in these little boxes.
And it says, look, you can go
and scroll it.
You scroll with your mouse.
You know, it scrolls that section.
It says you want to go to the next one.
Hit tab.
Hit enter to open it up.
It's, even though, kind of like we were talking,
even though it's a user interface,
like with scroll bars and I can grab the scroll bar
and go to it and I can click on the things and so on,
it's also very keyboard friendly, right?
This is probably a super important aspect
of building these types of applications in the terminal
because people expect that, right?
Yeah, very much so.
So a lot of text was inspired by web development
because I was a web developer for many years.
And there's a lot of work being done
in interfaces in the web world.
Lots of work, you know, loads of developers working on it for years.
I wanted to bring some of that to Terminal,
but I also didn't want to lose what made the Terminal interesting.
Terminal is a very keyboard-focused thing,
so I wanted textual apps to also be very keyboard-focused.
The mouse is terrific for discovering things.
You know, you can move it around and there's tooltips, etc.
You can click those links or you can press the key.
But if you want to, if you use an app regularly,
you'll want to learn the keys.
So it is very focused.
You can use the keyboard for everything.
In the footer, that displays all the main keys.
You can also use tab and shift tab
to move around various elements.
You can use up, down to scroll.
So you could get by without ever using the term,
without ever using the mouse.
And it's there if you need it,
but you don't have to.
Yeah, that's incredible.
It's got code highlighting.
It's got a lot of different things.
For people who maybe want to get started with this,
I think there's two, let's say three,
three things that are worth looking at.
One, you actually, you said you were a web developer,
so you must have been a fan of Vue Source, right?
Oh, yeah.
So you added, you basically added Vue Source.
That's right, yeah.
You type C, it says so at the bottom,
and that pulls up the source of the current page,
just like you would at my website or any website, right?
Yeah, I want people to realize that the code behind that
not that complex but textual it looks like complex um what you're viewing at the moment is actually
markdown um which you might think that's quite hard to render markdown in the terminal and well
it is but we've done it for you so um you just embed a widget and somewhere in the code it'll
say yield markdown and then it'll have the contents and it renders markdown you see there's a code
block there with syntax highlight code
yeah well that's the magic of of these libraries right it's
hard once for you and then it's easy for other people.
Yeah. We suffer so you don't have to.
Exactly. I feel like the most, the biggest example of that in the Python space is Jupyter Notebooks,
right? All that interactivity and all that stuff, people are writing TypeScript and JavaScript and
all these kinds of things, you know, it's for, you know, Plotly and other plotting UI things.
And that's so Python people can write Python code and not write, you know, they're not creating
websites are just typing in a notebook and they get
interactive things, right? But that's
probably the biggest take one for the team
sort of deal.
Yeah, there's a lot of work
under the hood.
A lot of people that use
Jupyter Notebooks, that's their only
knowledge of Python. They think Python is
Jupyter and Jupyter is Python.
And that's fine. It's a tool
and it gives them access to
all this stuff which would be very hard
otherwise.
So yeah, I think Jupyter
is a great example of that.
Out in the audience,
And we have David points out JPTerm.
Are you familiar with JPTerm?
Yes.
Is that David Brokert?
Yeah, yeah, yeah.
The successor of MBTerm, and it's Jupyter, Jupyter Lab in the terminal.
Yeah.
It's gone
full circle.
It's like the Inception movie.
It
really is, right?
But you can embed the textual app inside Jupyter.
So you could have Jterm working in a textual app inside Jupyter
that's also displaying another notebook.
Yeah.
Incredible.
All right.
So if we go to the terminal where I got this running,
and anyone else out there listening wants to check this out,
you just run it.
And I was starting to say there's three places you should check out
before I got kind of starstruck with view code.
Okay.
So I think there's
probably
the best place to get started is to look at the widgets.
I don't know what you think, but just like, well, what can this framework do in terms of what are the building blocks that you can look at the widgets?
And then once you decide, okay, this is pretty interesting, I think people should check out the projects because there are some pretty interesting things.
I know we've covered the mom Python bytes that are built on top of textual.
And then just to talk about the graphics, what is
this game?
This is a game in inverted commas.
it's got different names
sliding tile puzzle
I think is the most common thing, you've probably seen it before
you've got a square
the square is made up of lots of little tiles
and there's one space and you can move a
square into that one space
and the goal is to reassemble
the image, but for here
I've used code
so you've got all these tiles with code on it
and you've got to reassemble it
into actual working code
which I think is what most people think
developers do. This is how we make code, just by
sliding
these tiles around.
Yeah. I remember one of my daughters, I can't remember which one, saw me typing out code.
And she's like, what are you doing? What is that? I'm working on this project, this program,
this website. That's what websites look like. Okay.
Yeah. My wife calls it the gibberish. She says, are you working on the gibberish? Yeah, I am.
That's incredible.
That's an amazing way to put it. Yeah. You know, I was just thinking the other
the incredible power of text, right?
You think of all these systems, the internet, Linux,
configuration, source code, design,
all of that is just words, right?
It's not working with GUIs and all that stuff.
It's just typing.
Text is, yeah,
very important.
I quite like websites that skew graphics
and have just kind of like typography-based thing.
I find you can more easily extract the information you need.
But most websites these days you go to
and loads of ads, loads of image,
they pop in and out.
The text seems almost secondary.
So I'm a big fan of just text in general.
Yeah, same.
All right, so people can play the game.
That's kind of interesting, right?
Like I said, I think where maybe it's more interesting
is talking about the widgets.
And when I look at this, you know,
what this reminds me of is it reminds me of
if I were to go over here and type Bulma
and go, which Bulma is very refreshing.
CSS framework that doesn't require build tools
and shaking and webpack and all that junk.
Or like Tailwind.
Tailwind is kind of a pain to work with,
but it's also super beautiful, right?
When I look at this, the widgets,
it feels very much similar to that, right?
I'm sure people have checked out CSS frameworks.
Yeah, that's...
Yeah, tell us about it.
Yeah, so I mean, you know, again, coming from the web,
I want to have a web-like experience.
Because everybody's familiar with the web.
It's like you can sit someone down on a website
and they'll be able to use it.
I wanted the same thing for terminal apps.
You know, some terminal apps have a bad reputation
and have been hard to use, and it's mostly deserved.
Like, you know, how do you quit Vim?
It's a running joke.
I don't know how to quit Vim.
You reboot your computer.
Everybody knows that.
Come on.
Exactly.
I wanted, like, an interface that people were very, very familiar with.
this is actually in alphabetical order
but I think buttons was actually one of the first
thing I developed
because the terminal doesn't give you
anything for free, the terminal is just
text with escape sequences
for colour and style
like italic, bold etc
but there's no escape sequence for a button
the most simplest atomic
user interface thing
a button with a bit of text that you click
there's nothing in the terminal spec
for that, so you have to start from scratch
and we built this button that looks button-y.
It even has a 3D
sort of raised
effect
and stuff.
Yeah, so there's a lighter color at the top
and a darker color at the bottom,
and it looks like a classic Windows raised button.
Imagine if this light is coming from the top
and illuminating the top edge.
Some people don't like them.
I think one of the reasons is it has to take up three characters.
In order to get that effect, you have to take up three lines.
So it creates quite a chunky button.
It looks like a button, but it's chunky.
But you can style it very trivially to be one line long,
so your button can just be as tall as it needs to be.
Nice.
Yeah, these are great, and we've got other things.
I was thinking as you were talking about
primitives you have to work with,
I was thinking of pretty much every 3D rendered thing that people see,
video games and others as well, animations.
They're just triangles.
There's just a bunch of triangles, which is so insane that you think,
that thing that looks like a real forest,
every single thing on the screen is some weird triangle
with a texture and stuff applied to it.
But a lot of triangles.
Lots.
You can't think too hard about how fast things are happening
on graphics cards because your mind will melt.
It's like there's so much going on.
You've got check boxes.
Is it all?
Radio buttons.
Radio buttons, which are great.
A lot of the things that people might think about, data tables, you know, this is, if you're doing data science, I think one of the things worth talking about, because when we talk about some of the performance things, there's a lot of this within that within that, right? Like, like in your data table. So this whole UI, I can scroll up and down and see all the different widgets. But then when I get to the data table section, I can scroll horizontally and vertically within the data table itself,
right?
You can also press Control-A, and that'll maximize it.
Oh, yeah.
Very cool.
I didn't even know about that.
Yeah, this is a nice feature,
which I think websites should have and GUIs in general.
I remember Windows used to suffer from this.
You'd get like a dialog where you had to enter a lot of text,
but the dialog was this size,
and you weren't allowed to resize it.
You can't resize it.
Yeah.
Or you tap over and hope you hit the right button that you can't see.
Yeah.
So I added a shortcut key,
which can maximize anything which is focused.
can make it resize it to the size of the screen.
Nice.
Okay.
In the interest of time, let's go and talk about projects real quick.
I think one of the things that probably can inspire people a lot is some of these projects
here.
If you go to the project section, you've got a couple that are super nice here.
For example, I would say this posting I know by Darren Burns is pretty interesting.
This is like postman, right?
Like an HTTP client, but entirely in your terminal.
I'll tell people about this.
is great.
Yeah, so this is something that
Darren Burns built and he's
a developer of, one of the
developers, and he made a fantastic job of this.
This is not a textualized project
but basically it's Postman
which is a tool for making
HTTP requests. You might
use it if you're developing an API
and you want to experiment
and you don't want to have to build all the tooling
to talk to your API. You can just go straight
into this interface and experiment
and play around with it.
I did that two days ago.
Yeah, and it's super useful.
And the fact that it's in the terminal
is completely appropriate for this kind of application
because
that's
where you're going to be a lot of the time.
It just seems to be the right place.
If you have your app in a browser,
it can take you out of your flow if you're developing
and having to switch over a window.
But having it all on the terminal is super useful.
And this project has sort of grown in feature set
and I think it's comparable to some much, much larger projects,
including Postman.
Yeah, nice.
And open source,
right?
Open
source, yeah.
Yeah, cool.
What other ones do you want to give a quick shout-out to?
Well, yeah, we'll go through them there.
We've got Memory
that was written by Bloomberg.
They were an early adopter of Textual,
and it's kind of a memory profiler,
so it can run your Python application
and it can pinpoint exactly what's taking up too much memory
or if you've got a leak, you know, you're in a loop
and you've been reserving objects, you don't know about it,
it can alert you to that,
which is very hard to actually debug without any kind of tool.
So that's a fantastic project.
I
had them on not too long ago to talk about it,
and yeah, this is a super cool project.
I think also just graphically, it's pretty neat, right?
Yeah, it displays all the information that you need
right there in the terminal in a nice way.
I mean, I can imagine a previous version
of something like this writing out a big spew of JSON,
which you then got to study to figure it out.
We've saved a CSV file.
Now you can look at it.
It's like, oh, great.
Yeah, exactly.
But if you can look at it in a graphical form
in a nice table,
you can visually parse information much quicker
so you can pinpoint things.
We talked a little bit around this,
But another huge benefit of these types of UIs with Textual
is the ability to run them remotely on servers and other,
or on a Raspberry Pi or on things that are embedded types of stuff
that you just only access through the terminal, right?
Like if you wanted to do memory on your web server,
you probably don't want to just open up a bunch of ports
and start serving, you know, a parallel HTTP request over it, right?
But if you SSH in and you just run this GUI that's updating,
it's really nice, right?
Yeah, exactly.
You don't even need to have a desktop.
You don't need to run a server.
And like I said, you don't need to set your firewall
to allow a particular port and configure applications.
All that's gone.
Because it's a text interface,
you just need to have a shell SSH into the server
and then run it, and you can see this nice interface there
because it is just purely text.
And there's not much text involved.
You'd be surprised about text that needs to be sent over the wire.
is surprisingly minimal.
If you compared it to a YouTube video
of the lowest quality,
I don't know what the lowest quality is,
like 120p or something.
Yeah, 360 by 240 or something.
Who knows?
Yeah,
that would be vastly more data
than a text interface like this.
Yeah, even if it's madly updating, yeah.
I mean, you could actually.
You could if you want to push it.
Like if I was to run this ridiculous demo
with a spinning gradient at 60 frames a second
and setting the screen size to ridiculous.
It might turn into a video, but for most interfaces.
But is it probably applicable for like GZip transfer as well?
You know, text compresses really well.
I don't know.
True.
It depends what you're rendering.
I don't know if SSH does.
I don't know.
Maybe it does.
I would think it compresses.
Compresses and encrypts.
Yeah.
I would
hope
so.
Yeah, well, compression should be cheaper than the encryption.
So yeah, why not go ahead and compress it while I'm at it, right?
Exactly, yeah.
Yeah, yeah, yeah.
Okay.
So somewhere in here, we've pulled up so many things.
I pulled up your article that I wanted to talk about as well.
So let's talk about this.
This was your, you said you wanted to write an article,
sort of celebrate the 1.0 milestone for Textual.
And the article was called
Algorithms for High-Performance Terminal Apps.
And I thought there was just some fun things to pull out of here.
So I thought we could maybe talk through some of them.
Yeah, sure.
So there's lots of interesting technical problems to solve with Textual
and lots of cool solutions.
But I still rarely have the chance to talk to anyone about it
because it's one of these things that's kind of under the hood.
It just works.
Yeah.
There's nothing to discuss.
So I wrote this blog post to describe some of the cool things that go on.
The most core part of Textual is the compositor.
This takes all the widgets.
If you've got an interface, it might have data table, button, checkboxes.
And there might be loads of those, and it might be able to scroll through it.
And Textual has to take all those widgets and assemble them into a single update.
Because there's nothing in the terminal that does a kind of a tiling window manager.
You just write text to the terminal.
So the software has to create this illusion that you've got windows and things that are overlapping.
and that's essentially what the compositor does.
That's
great.
And you've got transparency.
Oh my goodness.
Yeah, it's kind of magical.
It shouldn't be possible in the terminal.
It should not be possible.
It cheats.
You're not seeing true transparency
because the terminal is not capable of it.
You can't put an X on top of an A
and then see the X translucently
with an A in the background.
But you can change background colors.
So if you put something on top of background,
you can calculate the transparency on top of the widget underneath it.
So you can create the illusion of background of transparency.
And that's something that the compositor does as well.
Is textual pure Python?
Pure Python, yeah.
I had thought that at some point we would have to write something in Rust.
And I bought a couple of Rust books, which I haven't read yet.
But every time I got to a point where this is a bit too slow,
I found a very good optimization in Python.
So it turns out that it's just not necessary.
I mean, if we were to write some core code in Rust,
I don't think we'd get marvelous speed up.
We might get 5%, 10% if we're lucky for a lot of effort.
But since it runs on a lowly Raspberry Pi, it's not been necessary.
Python's been more than fast enough.
Yeah.
And you can just ride on the coattails of the faster CPython team.
Oh, yeah.
Yeah, I mean, yeah.
That helps too.
A new
version comes along, we can say Textual just got 10%
faster.
Textual has some sort of concurrency framework too, right?
Yeah, so it's based on asyncio.
And every widget from a button to a text area to a checkbox runs an asyncio task.
So all these things are running concurrently, potentially updating the state.
and Textual will update things
according to the schedule of the widgets.
You might have a widget which, say,
updates 10 times a second,
another widget which updates when you press a key,
and another widget which updates infrequently.
And Textual will combine those updates
into a single update so that it looks clean,
it doesn't flicker,
and it's what does the magic of updating things.
Yeah,
awesome.
That's super neat.
I think UI frameworks and AsyncIO, Async and Await,
they make a lot of sense, right?
It's event-driven stuff, and so you can,
instead of pulling or whatever, you just say,
I'm going to wait until this thing
has
some kind of event,
and then I'll work on it, and if that doesn't have an event,
I'm going to go work on something else.
Yeah, it's pretty cool.
Yeah,
exactly.
It's funny that AsyncIO was obviously, you can tell by the name,
it wasn't intended to build user interfaces,
whether in the terminal or not, it was built for I.O.,
but it's very good at handling concurrency of any kind,
including text user interfaces.
So I'm a big fan of Async.
It's not perfect.
There are a bunch of gotchas which come up in our support channels.
For instance, someone will be playing around with Textual
and will say, well, I'm going to need some long-running tasks,
so I'll simulate this by putting a sleep in.
We'll do like sleep 10.
The whole app
just locks up.
I can't believe it.
Exactly,
exactly.
So it's not perfect, but there is no perfect solution to concurrency.
But I think it's as good as it can be with the current level of technology, I think.
Yeah,
yeah.
Yeah,
very neat.
Free-threaded Python?
Is it going to
influence that
kind of thing?
I think so.
There's a whole lot of cool things that free-threaded Python can do.
We've kind of convinced ourselves that we didn't need that kind of level of concurrency,
you know, from like a web application or something, because it's really linear.
and the I.O. gives you concurrency
in a sense because you're waiting for the I.O.
But I think
we need a better abstraction for concurrency
because having to
explicitly create a thread
and run it requires that you think
in terms of threads
which is quite challenging.
I think it should be
the same as async.io. It
should be async
and await.
I think that would be a marriage
between them where like you don't really know as you're consuming it you know
yeah
unfortunately
async io is single threaded you can use multiple threads but you've got to consciously write the
code i would like to see an async io
where it just distributed work
across the course if it's if it's
io based just keep it on the same thread but if it's computational based then like you're going to
just put it on another thread and give me a future sort of thing to await and we don't care
yeah
Absolutely.
Yeah.
So I think in the future,
we're probably going to get something like that
because I think Python is so valuable
that people are going to want to use it more
and they're going to build these better abstractions.
So I imagine in a year or two,
maybe less,
we'll have an asyncio that's rethreaded
or something like it.
Yeah.
We say that we don't need it for web apps
because we can just scale them out, right?
We'll just run four of them, four worker processes.
but there's a big memory cost to running.
Well, I've got 16 cores,
so I'm going to run 16 worker processes, right?
They each take half a gig.
All of a sudden, you're like,
eight gigs just for this.
Just so I can get computational parallelism, right?
Yeah.
Exactly.
I mean, yeah,
the IO gets you a lot of the way there,
but sometimes you accidentally create CPU-bound code,
which would run very poorly.
But if you're using all our threads efficiently, then that should be easier.
It should be easier, yeah.
You know,
it's super easy.
Like, oh, I've
got an ORM and I'm going to return 20,000 things that I'm parsing into Pydanic objects for FastAPI.
All of a sudden, like, most of the work is the serialization that's computational.
Anyway, all right.
So let's get back to this.
But I think that's super, super interesting.
We could do a whole other hour on that.
So one of the things in here you talked about is thinking in segments and not characters or stuff for drawing terminal lines.
Let's talk about that because I really want to talk about the switching the primitive idea you got, but I think this is a good setup.
Yeah, sure.
So people who aren't familiar with inner workings of terminals might look at terminals and think it's like a two-dimensional array of characters.
It does seem like that.
And if you're building a textual app, you might think that you could compose a screenful of text like a bitmap, as if the characters were pixels.
And as developers, that would be like stuff we're very familiar with.
We could easily build that
and
create stuff with it.
But the problem is that terminals aren't two-dimensional arrays of characters.
And it's for one reason is that some characters take up twice as much space as others.
Chinese, Japanese, and Korean tags typically take up two characters
because their characters are more complex.
They deliver more information in a single character,
so they have to be wider.
There's also emoji, which many emojis can take up twice as much space.
I'd have the snake emoji.
Exactly.
I think that might be two.
I don't know how wide it is.
Some emoji are one, like a smiley face or something,
but some emoji are two.
And if you were to treat it like a two-dimensional ray,
it kind of falls apart at that point
because if you subtract one from the Y coordinate,
it's not directly above the original coordinate.
So in situations like that,
rather than trying to fudge
things
into the primitive
that you first thought of,
you can come up with a new primitive,
a new way that represents the very lowest common denominator
of thing you want to do.
And for textual, that turned out to be segments.
So rather than a character, it's like a pixel.
We use a segment.
A segment is a string, any number of characters, plus a style.
And by assembling these segments, you can represent anything in the UI.
And all the operations which are done are kind of built on segments.
So I call this switching the primitive,
because the original primitive was like a character's a pixel, right?
Which didn't work.
If you were to, you could use that with a bunch of fudges to build on top of it,
but you might find that it falls apart.
Things which should be straightforward suddenly become really complicated.
And that's because as developers, we tend to layer primitives on top of other operations.
And if the very foundational primitive doesn't represent your problem very well,
then it can fall apart.
So the switch from pixels to segments worked very well with Textual.
and Textual is essentially a segment processing engine.
Everything the compositor does takes in a bunch of segments,
manipulates them, spits out new segments,
and then those get turned into escape sequences.
Yeah, very cool.
I think this idea of switching the primitive,
you know, people who are new to programming or new to Python,
especially programming, I have a hard time.
I see the code, I look at someone else's code,
and I see the code, and it makes sense,
but then when I sit down with a blank screen and try to solve a problem,
I'm stuck. I don't know what to do.
And this switching the primitive concept of like,
we looked at it this way and it just seemed so complicated and intractable.
And then I decided to rejigger maybe the data structures
and how we organize stuff and how we combine them.
And boom, it just unlocks simplicity, actually.
Kind of like going back to our triangles and graphics.
It's like, well, if you think in pixels, 3D game engines are impossible.
With ray tracing and lighting and shadows,
you think in triangles, all of a sudden it unlocks it, right?
this sounds a little bit similar, and I think
that's a pretty valuable lesson for people to take.
That's exactly right. So if you had
a game engine, and the only
function it had was like put pixel,
it would be a nightmare
to build anything but the most trivial
games, but the primitive of
a triangle means you can build 3D
anything. So that is the bare primitive.
And they have angles, so they have reflection,
and so they have all sorts of stuff, yeah.
Yeah, something similar came up when
Darren was building the text area.
So the text area has lots of operations,
like insert a new line, delete a character,
delete a line, delete a paragraph, cut and paste, etc.
And the primitive for that boiled down to a very, very simple primitive,
and that was replace a range of text with new text.
It's like anything you can do to a text area
comes down to that primitive of a range plus new text.
Like to delete something, you replace a range with an empty string
to insert something.
You replace a range with
the insertion character,
like a new line plus the previous
string. So everything boils down to one
very simple primitive.
And once you've found the right primitive,
bigger problems become much, much easier.
Yeah, 100%.
It's amazing the way it works.
So we'll get short on time.
We got, pick one more
lesson from here that you want to
talk about maybe. The spatial
map was quite interesting.
Yeah, I think they do.
A bit further down, yeah.
So one of the problems we had in textual,
when interfaces get complex,
we've got lots and lots of widgets.
Some of them are visible and some of them are not.
Some of them are scrolled off.
They're still there in memory.
We know exactly where they are.
And when we come to render that,
the most obvious way to do that
is to step through them in a for loop
or widgets in all widgets,
do stuff to widget.
But that means we're iterating over all the widgets
every single time,
even if they aren't visible.
So the spatial map was an attempt to optimize that.
Basically, it's a very quick way of deciding
which the widgets are on screen
and which the widgets are currently scrolled off.
So we literally don't need to even loop through
the scrolled off widgets.
And the way we did that briefly
is we kind of logically separated the terminal
into a grid.
There's a step where you go through
and assign every widget to the grid squares
that it might overlap with.
small widgets might be right inside a grid square some may overlap one or two or more and then once
we've got that information it's very easy to pick out which widgets are visible and exclude which
widgets aren't because we can take the screen figure out which of the grid squares it covers
and then we can go through those grid squares and there's probably just a handful of them and each
of those grid squares is associated with a list of widgets which are under that
you
can combine that
with a set and then very quickly
you reduce that problem domain
from being potentially unbounded very
large to like very small
some of the widgets might actually not be visible
they might actually be in a grid square which
is off the edge of the screen
but we can just loop through those
and discard those ones
but that's a much smaller operation
than
looping through every widget
in the location. Interesting. He talked about
it's fast enough in Python
and it's this kind of stuff that makes it fast enough
in Python right? If you rewrote this in
other native compiled language,
it
would be faster to go through every single one of them,
but you're still potentially processing
a tremendous number of things,
and you get the compositor and overlap
and all those kinds of things,
and you're really worried about stuff
that's way off the screen.
Instead of going, we're going to rewrite it,
you can just think, let me think about
the right data structures and the right algorithms.
Exactly.
And so on, yeah.
I mean, I would love it if Python
just got so ridiculously fast.
You don't have to worry about that,
and I'll take any speed improvements again.
But the optimizations you can produce yourself
just by having the right algorithm,
they tend to outweigh the benefits you could get
from, say, running it in C.
First, it would be implement that in C.
It would obviously be faster,
but it would still be much faster to have that algorithm.
Yeah, exactly.
I'll take my order of O squared
versus your O factorial versus N squared.
You know what I mean?
Exactly.
It's going to lose
on N factorial no matter what you do, right?
Yeah.
I mean, Python wins because of the speed of development.
We know it's not the runtime speed.
Yeah, absolutely.
The runtime speed is okay most of the time,
but it's the speed of development.
The fact that you have got more time to pick the right algorithm
means it's not as slow as people might think.
Yeah, absolutely.
It doesn't get too complicated.
Yeah, thinking about this,
I think there's a lot of
parallels
back to game engines
that I think about a lot.
The game engines have this thing called oct trees,
like basically break stuff into eight squares,
and you say, well, which I'm looking for a thing
if it's going to say intersect with this, right?
Because it's like for hit detection and stuff.
Like, well, is it in this half of this world
or that half?
Well, it's in this half.
Okay, well, we're not even going to compare it
against half of the things in the world
that are in that half.
Now, look at the hash, right?
Like you can super quickly go,
I have a million objects on screen,
but I can determine if this thing hits it
with five comparisons or something like that.
You know what I mean?
With just the right data.
That's exactly it.
It's super interesting.
Yeah, yeah.
It's probably no coincidence that I used to work in video games.
Oh, did you? Okay, yeah.
Yeah.
So that was kind of my mindset.
It's like reducing the problem.
And Textual is quite a lot like a video game.
If you imagine like a 2D video game that's got lots of sprites that are over here,
we don't want to worry about those.
Yeah.
Replace sprites with widgets, and it's pretty much the same problem.
Yeah, yeah, exactly.
It's the same kind of mindset.
It certainly is.
All right, well, I think we're going to need to
just kind of wrap it up here
because I think we're getting short on time.
Let's leave everyone with roadmap.
Where, you know, you've hit this 1.0 milestone with Textual.
Where are things going?
So there's a whole bunch of features which I want to implement.
I mean, Textual is usable as, you know, you can build fantastic apps,
but there are a few things where we don't have parity with web apps.
Something I've implemented on a feature branch is arbitrary text selection.
So, you know, on a website, you can just draw your mouse over text you want to select.
That didn't work well with 2Es.
If the terminal did it,
if the terminal doesn't understand the logical separation of widgets,
it would just copy all the text on that line,
which might get parts of one widget and parts of another.
So I've implemented Arbority Text Selection,
which seems to work quite well.
And it's such a fundamental feature, I think.
Wow.
It'll make Textual more useful.
Yeah, I guess if you've got
a UI in Textual,
and you're like, I need
to get that and paste it into another document
or search it, you know, highlight the map,
the address to put in a map or something, right?
Yeah, and things like, you know,
if you're using Textual to talk to an LLM,
an LLM writes some code,
you don't want to transcribe that code visually.
Yeah, and so now we can be able to like,
we can select the entire code.
You could add a button,
but it's very convenient to drag.
So that's something that's coming very soon.
And yeah, there's a whole bunch of features I've got,
which I'll be working on.
Yeah, watch this space.
Excellent.
And PRs accepted, contributions accepted?
Very much so, yep.
There's a big pile of them there,
but I tend to work on a big feature
and then spend a few days going to the PRs.
And I love to have PRs.
It means that people are very interested.
And it saves me time, of course.
If someone else is fixing bugs and writing code,
then it's a great thing.
Awesome.
All right, well, thanks for coming on,
giving us an update on Textual
and all the stuff that you guys built.
It's super valuable to people.
Always a pleasure.
Thank you very much.
Yeah, you bet.
See you later.
Bye-bye.
This has been another episode of Talk Python to Me.
Thank you to our sponsors.
Be sure to check out what they're offering.
It really helps support the show.
This episode is sponsored by Posit Connect from the makers of Shiny.
Publish, share, and deploy all of your data projects that you're creating using Python.
Streamlit, Dash, Shiny, Bokeh, FastAPI, Flask, Quarto, Reports, Dashboards, and APIs.
Posit Connect supports all of them.
Try Posit Connect for free by going to talkpython.fm/posit, P-O-S-I-T.
Want to level up your Python?
We have one of the largest catalogs of Python video courses over at Talk Python.
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.
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 talkpython.fm.
We're live streaming most of our recordings these days.
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.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.