Python has many string formatting styles, which have been added to the language over the years.
Early Python used the percent operator to inject formatted values into strings, and we have string.format, which offers several powerful styles.
Both were verbose and indirect, so fstrings were added in Python 3.6, but these fstrings lacked security features.
Think about little bobby tables.
And they manifested as fully formed strings to run timecode.
Today, we talk about the next evolution of Python string formatting for advanced use cases.
Think SQL, HTML, DSLs, and so on.
t-strings.
We have Paul Everett, Dave Peck, and Jim Baker on the show to introduce the upcoming language feature.
This is Talk Python To Me, episode 505, recorded May 13th, 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.
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/Posit, P-O-S-I-T.
And it's brought to you by Auth0.
Auth0 is an easy-to-implement, adaptable authentication and authorization platform.
Think easy user logins, social sign-on, multi-factor authentication, and robust role-based access control.
With over 30 SDKs and quick starts, Auth0 scales with your product at every stage.
Get 25,000 monthly active users for free at talkpython.fm/auth0.
Dave, Jim, and Paul, welcome to all three of you to Talk Python To Me.
Paul, welcome back.
Dave and Jim, welcome for the first time.
Awesome to have you here.
Thanks.
We are going to carry on an amazing tradition of Python string formatting.
We've had the percent.
We've had the plus.
We've had the dot format.
We've had the dot join.
Everyone was very excited about fstrings back in 3.6 when they came out.
And now, after quite a bit of work from the three of you and others, we're going to be talking about PEP 750 t-strings.
Amazing.
So congratulations on all of that.
I think it's going to be a lot of fun.
People may be surprised to think that, oh, there's an entire episode with three whole people on string formatting.
Yes.
Yes, that's right.
There's actually a lot to it.
This is a pretty rich API and a pretty big advancement.
So we're going to dive into that.
But before we do, how about a round of introductions?
Dave?
Hey, I'm Dave Peck.
I'm a freelance software developer based in sunny Seattle, Washington.
A freelance software developer is a polite way of saying I'm a computer weirdo.
And I get to get into hopefully all kinds of good computer mischief, like working with Jim and Paul on new peps for Python.
Awesome.
Great to have you here.
And always good to have another person from the Pacific Northwest.
Jim, welcome.
Hi.
So, yeah, I'm a longtime Python user.
I used to be very actively involved in the Jython project, which let me really learn the internals of both Jython and CPython, since we had to maintain a compatible implementation.
So, you know, got deep into things like compilers and the standard library.
And, yeah, it's great to talk about template strings or t-strings with you today.
Paul, welcome back.
How many episodes have you been on? Many.
I don't know. Not enough, because Brett's ahead of me.
I know.
Brett Cannon, you're not allowed to be on Talk Python for five years until I catch up, and then you can come back.
Well, you should also send your message to Anthony Shaw, who I think is currently on the leaderboard, number one.
He's been on a lot.
Yeah,
and then you were talking with Chris McDonough, who was like episode three or something
like that way
back in the day.
Briefly, I'm Paul. Hi, I'm Paul.
I am now head of developer advocacy at JetBrains, the PieCharm people.
I make coffee for Jim and Dave on this project.
I let Jim do all the big thinking, and I let Dave go out and explain to complainers that we heard the same complaints for f-strings back in the day.
So this has been a super fun
project to be on.
Yeah, it's very exciting, and I'm super interested to dive into it.
Something I didn't really know a lot about.
Let's dive into it, right?
what are t-strings and why do they exist?
Weren't f-strings good enough?
I mean, they look kind of like f-strings when we use them.
Yeah, that's a great part about them, right?
They look like f-strings.
They behave a lot like f-strings in terms of technical issues like the scoping of the interpolation expressions, but they're not f-strings in a very profound way.
One of the things that we wanted to prevent was stuff like, you know, the classic XKCD comic about the Bobby Tables sequel injection, okay, where it becomes a drop tables inadvertently.
And we can get, yeah, exactly.
The traditional exploits of a mom.
This is your son's skull calling.
Did he break something well in a way?
Yeah.
And so this is, you know, the original language of the PEP actually referenced directly Bobby Tables in this comic.
For whatever reason, we removed that, but we don't have to do that today in this conversation.
It was a big driver for this work.
And the reason is that f-strings are great.
They're great for formatting, but they're also sort of a trap, I think, for people to use because it's you're formatting things, everything is working.
and, oh, by the way, you just introduced the HTML injection or SQL injection, or you just happen to have something that doesn't format properly because you didn't consider a particular corner case.
What we really wanted to do was move a lot of that out of the usual user experience and into a library that could go, some library, something for HTML, something for SQL, something for some other domain-specific language that would allow it to go and handle that appropriately.
We'll get into more about what that means, I guess, throughout this conversation.
But that's really where we started.
We wanted the simplicity of using f-strings.
We can get into more about what that means, but without some of the hazards.
Excellent. Excellent introduction.
And it's important that this is part of the language.
It's officially accepted in Python 3.14.
Oh, will the jokes overflow about Py, this version of Python,
when
it comes
out in the fall?
It's a memorative edition of Python.
We're so glad to get into it.
That's right.
It's super cool.
So it's going to be part of the language.
And the reason I bring this up is it seems like it needs to be part of the language, not just an external library, to really take advantage of it and not be just some API.
You construct strings in some weird string builder way, but through literally just, quote, start typing stuff, that has to be part of the language, right?
Yeah, that's exactly right.
I mean, as Jim mentioned, f-strings are wonderful.
The syntax is powerful, it's robust.
It became very popular because of that.
But of course, there are these foot guns of using them for, you know, SQL and HTML where you might run into some injection problems.
With t-strings, the key difference is that while f-strings evaluate to the standard string type, t-strings evaluate to a new type that's shipping in Python 3.14 later this year called template.
And so while they look like the literal form looks like any other string, they're quite different in that respect.
And the key thing about the template type is it lets you, as a programmer, decide what parts of the string were statically authored and what parts of the string were dynamically substituted or interpolated.
And so just being able to do that as a language feature is a really big deal.
It's not something you can do with fstrings directly.
And once you know those things, you can start to say, okay, this is a SQL statement.
Maybe I need to do something with the interpolation like escape its value before I construct the final string that I'm going to send over to my database.
Yeah.
If somebody were to work with an F string, it does the cool interpolation at runtime.
However, the thing that your API or any sort of code gets access to is just the resulting string that comes out.
And I think this is probably the biggest piece of understanding that people need to wrap their heads around.
And we'll dive into some of the things people do need to wrap their heads around and how it's different.
But instead of getting just here's the string result, which who knows why it says --drop table there.
Maybe that's what they want.
You don't know.
Right?
But here you would have here's part of the string.
And then here's a place where a value goes with a name.
And that thing, if you look it up by name, its value is --drop tables.
well, maybe we'll escape that or whatever.
You know what I mean?
Right.
You and Brian covered it twice in Python Bytes.
And the first time, I'm going to exaggerate a little bit, but Brian was like, what is this?
Why
do we need it?
We have enough, right?
The second time, Brian was like, oh, I get it now.
There's going to be a lot of that, Paul.
And we certainly
will have some explaining
to you.
Yeah, there's going to be a lot of this.
As Dave said, being able
to get at this.
Sorry.
What's that?
Sorry, there's going to be a lot of that.
There's going to be a lot of like, we already have f-strings.
What is this?
Yep, sure.
An F string gives you a string.
A template string gives you a template.
And then later you will get a string.
Later means going through a function.
They can go and do cool things for you like escape values.
Or you're doing an HTML templating system.
Pass it a dictionary and it will generate a style attribute with some policies along the way.
pass it a false or a Boolean and it will elide the entire thing or do all kinds of other things.
Having the template structure that Dave described gives business value DSLs a chance to step in and operate on structure rather than strings.
So when I write this code, I say value equals T, some interpolated string sort of thing. Is it interoperable with a string in the sense that if I have a function that expects a string, could I pass it? Much like path from pathlib kind of goes where string file names go,
or does
the thing working with it need to know, no,
it needs
to be transformed, like you say, like process this to a SQL statement or process this to an HTML fragment, and then you get a string.
Yeah, and for templates, the answer is, very intentionally, they are not the same as strings. And so library authors are going to have to update their SQL libraries and their HTML libraries to expect this new template type.
And that's very intentional.
The other thing I would say is that templates don't have a direct route to strings.
So if you call str of template, you just get the default repper back, right?
Which is probably not something you want to be showing your users or it's not HTML that you're trying to render.
And that,
again, is very intentional.
It's also unlikely to cause injection attacks and whatnot as well.
you're getting that
reference. So much, you know, all those parentheses and braces and whatnot, not likely to happen.
Yeah, absolutely. And so library authors will have to update their libraries to add new methods that expect this template type. And presumably those methods won't also take a string. You know, if you're concerned about injection vulnerabilities, presumably you want to take this new dynamic template type that tracks what parts of the string are interpolated and what parts came from the developer themselves.
Right. And treat them differently. Yeah. Yeah. Very interesting. So let's just talk about that a little bit. I see some use cases in the chat, but maybe we could list out some more. So for example, Nym4 says structured logging, preventing cross-site scripting, SQL injection. What are some of the motivations here?
Yeah, those are all great use cases. Any type of injection vulnerability. So SQL and HTML were obviously at the top of our minds.
But another one that, in fact, there's potentially a new PEP coming around for that's being discussed right now on the Python discussion boards has to do with command injection.
So when you shell out, you're worried about the user-provided values there as well.
Give me a sec.
I'll try and remember what the actual PEP
number is.
There's os.system,
and then
you can give it a command like echo some string from the user.
But it could, of course, be some string, quote, ampersand, ampersand, rm-rf,
or something like that, right?
And of course, as Paul mentioned, once you have the tools to help you prevent injection vulnerabilities in sort of a more general way in this general purpose fashion, you also have the ability to do all kinds of other fun and powerful things like what Paul mentioned with HTML, which is, hey, I don't just want to write, you know, a single attribute.
I want to give you a dictionary and you write 20 attributes based on the contents of my Python dictionary.
And there's no reason you can't do that now, which is exciting.
Yeah, I
would add to that
if you wanted to, for example, do some interesting complex analytical SQL, where you're using common table expressions, or even you just want to go and have your analytical SQL.
I want to be able to do it on this column name versus some other column name.
We want to make it possible to do that in a safe fashion.
These are things that are difficult to express with some of the typical wrappers that we might use with SQL, like SQLAlchemy.
Maybe like, I don't think you can really do like CTEs and Django query sets and whatnot.
But what I'm trying to say is that both of those tools do allow you to access raw SQL.
But now you need to be able to compose that raw SQL in a way that's safe.
and uses the information about where this interpolation is happening in order to properly put it in place.
So if you are in a situation where maybe that CTE is something you can access, you can go and say, okay, I can insert it into the SQL or maybe a little more common usage here for a lot of people.
I don't know how many people use common table expressions.
I do.
is to go and, you know, I just want to, again, select from this particular table name or this particular column name in a safe fashion. Or I want to go and use values that can't be properly expressed with placeholders. But maybe if I use like a, you know, a temporary table to insert it in. These are all techniques that we use when we do this sort of work. But now we have this opportunity to bring it into directly in the library and then make it possible for users to use it without really having to think, where did this come from? How do I go and make this such that it can be used in a where in clause, for example, that sort of thing.
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 our studio, they've been building out a suite of tools and services for Team Python. Today, I want to focus on hosting your Python-based data science workloads. This includes dashboards, reports, plots, interactive web apps, all the way to custom Flask and Django apps. Their service is Posit Connect. Posit Connect makes it easy for data scientists to share work built with Python code. If you have a Streamlit app, Dash, dashboard, Plotly interactive plot, a FastAPI service, or even a Quarto report, just give Posit Connect the code it needs to maintain the asset and Connect automatically does the rest. Connect will manage your APIs and serve your interactive apps for you. And if you want, you can update your reports and dashboards on a scheduled basis. That's right. No need to explain to the stakeholders why that dashboard or plot stopped updating last week. You get to focus on your data science and leveraging your skill set while Connect makes you look good, keeping your code running and private.
With Connect, you get a private URL on your Connect server, ensuring that your asset is continuously available to your shareholders. And you can control which users have access to the asset. Let Posit Connect handle the delivery and DevOps involved in sharing your work.
You focus on what you do best. So if you work on a data science team, you owe it to you and your org to check out Posit Connect. Visit talkpython.fm/connect today and get a three-month free trial to see if it's a good fit. That's talkpython.fm/connect. The link is in your podcast player show notes. Thank you, Deposit, for supporting Talk Python To Me.
If I may, real quick, I got to give Jim a lot of credit on this as we've gone through the years on this. And Jim taught programming languages at University of Colorado Boulder. And so he knows all these patterns and all these languages and the implementations from his Jython years and stuff. And even now, he's still talking in chat about, hey, you know, Last year he was talking about how domain-specific languages could apply to Pandas and other data science stuff.
And now he's talking about LLM interactions and chat and stuff like that, where you've got a little language, but it's got a little bit of structure.
And what if you could, and then 500, you know, Discord messages later, Jim has invented something new and interesting.
So it seems to me like there's also some interesting possibilities for like lazy evaluation for also some possibilities for like query optimization.
You know, Jim was talking about databases, but there's a lot of different things, both from a performance perspective, but also potentially just from a tightly versus loosely coupled systems.
Like maybe you could say something to the effect of like, and the username goes here, but that part of the system logging doesn't know what the username is.
But somehow as the template gets rendered, the additional pieces could get filled in with real details, like the IP and the username is actually this, because over here we know.
But when the logging happened, we got a template that just said, well, whatever you figure out, it goes here.
How much of those things are possible now?
Like, could you look at the structure bit of SQL and say, well, if we reorder this, or if we put something about, you know, some kind of SQL hint or something about indexes or other things in there, could you maybe get more from it?
I was thinking someone might else answer this, but I will go for this.
I mean, I think that's possible to do.
In terms, you know, often we, you know, again, if we're thinking about SQL, we would, you know, dispatch this to, you know, some sort of, you know, the internal optimizer and, you know, whatever database you're working with.
But, you know, again, the, you know, again, using the SQL example, you know, there's, there are multiple ways that you could potentially interface some, you know, more interesting, complicated ways of interacting with SQL that are kind of hard to, you know, either you can't express easily with placeholders, you know, the standard name placeholders or positional placeholders in SQL, or just, you know, basically you find people going composing SQL.
and, you know, doing it in a bad way.
But if you were to go and, you know, there's like a popular tool called SQL Glock, for example, that allows you to take SQL, re-express it as an abstract syntax tree, and then what can you do with that?
Well, you know, the interesting thing about, you know, what we do with t-strings is it can be a front-end to such tools.
So t-strings themselves are, you know, intentionally designed to have just this very limited, but at the same time, you know, let's say, you know, very powerful, you know, integration with Python, right? You have, you know, effectively an f-string specification of, you know, what's going to describe that template. You describe the interpolations, they can be nested and everything, but fundamentally at the end of the day, you get this template object out of it, which could be nested and whatnot, but it's still this simple, straightforward thing. And then you pass it to a function that can do interesting things with that. From a performance perspective, that's also something that we intentionally put together. I don't know, Dave, if you want to talk about that, what we did specifically for that, because I think that might be something you want to speak to.
Yeah, absolutely. Well, if you take a look at what's inside the template type, there are basically two tuples that sit there. There's a tuple called strings and a tuple called values or interpolations.
You can kind of work both ways.
And so as you might expect, the strings are the static parts that are part of the literal string that you specify.
And the values or interpolations are the dynamic parts.
And we kind of made it so that no matter how you write your literal, it's always the case that there is at least one string in that strings tuple, even if it's the empty string.
So T quote, quote, gives you a template with no interpolations, with an empty tuple for interpolations, and with just a single quote for strings. And we ensure that there's always one more string than there are values or interpolations.
And the reason we do that is that allows you to basically, the string's tuple becomes a useful cache key in many cases for memorizing. So if you process a template once with your HTML function, you might sit back and say, okay, I've seen this structure of HTML before, and the next time I do it, all I need to do is fill in the gaps. And so that we think is just like a really basic optimization that you can use. And we're seeing that use, Paul, you might want to mention the TDOM library that I know you and others have been working on in the last little while. But it's just a basic optimization that we can offer. I think it is worth calling out, though, that, and I know we mentioned this earlier, but probably worth calling out once more just to make it explicit, that t-strings like f strings are eagerly evaluated, right? So if you have hello,
curly
braces name, and name isn't in scope, you will get a name error just like with an f string.
And so you might say, well, that feels a little weird to me because don't I want to reuse these things multiple times? And this is one of those cases where the word template is just an overloaded term in the computing world. And so if you're coming from the Jinja world or the Django templates world, you're probably used to the idea that I have this structure and I'm going to keep substituting values into it.
And that's a little bit different than the other use of the word template, which comes from, say, the JavaScript side of the world.
So JavaScript has tag template literals.
If you've written any JavaScript code, you've probably run across them before.
And there, like with t-strings, they're eagerly evaluated.
So, you know, of course, you have the full generality of Python available to you.
So you can just write a function that takes the parameters that you want to substitute and returns a T string, call it multiple times with different values, and you'll get different template instances out the other side.
Probably just worth calling that out so that it's clear to listeners that there is this kind of funny overloading the word template.
But yeah, back to the point about optimization.
We're pretty excited about just the basic opportunities for building optimized template processing code, like an HTML function or a SQL function that works on top of this basic structure that we provide in PEP 750.
Yeah, and I think one thing you can think about is, again, we may be getting a little too into the weeds here, but let's get into the weeds.
You can think about the template as basically providing this interesting way of describing your arguments.
And then you pass it to some sort of function, HTML, SQL, you name it.
And basically, it's going to evaluate with respect to those arguments.
But, you know, if you, so we basically, you know, if I have an HTML function, I'm going to want to look it up with that dot strings, template dot strings.
Say I parsed this and I know how to go and work with this fragment.
I already know where all the pieces need to go, the holes that need to be filled in by these interpolations, and it could be done very quickly.
And so we've put a lot of effort in terms of thinking about what is that optimization path.
And there's also related aspects.
Why is this another reason this is built into the language is because you can get lexical scope as opposed to dynamic scope.
You think that lexical, you know, you might think that dynamic scope is always the thing that's going to work for you.
But no, this is the thing that brought Paul and I together on this project.
It's exactly, you know, you can't use dynamic scope when you would expect it.
So, yeah, if we want to go to that scope issue when calling components from list comprehension.
So, Paul, if you want to speak to this a little bit, those are the problems you experienced.
Sure. And this is, oh, my gosh, Jim in the first round of this and Dave in the second round of this in the PEP and the comments.
This this damn thing had more comments on it than every other PEP in the history of civilization.
Almost it felt that way.
Major changes between the first draft and the second draft from lazy evaluation, tag template functions, all those things.
But one that comes up pretty frequently is I could just do this with this script frame.
And you can, but you can't and you shouldn't either way.
But there is a nuance about scoping that bit me right here on the screen in this ticket that was the origin story of Gemini talking to each other.
2020, a predecessor that mimicked t-strings in sysget frame from the people behind the JavaScript package called HTM. They did a port to Python called HTMPy for doing powerful template languages kind of closer to the language, something that in the JavaScript world, this is a replacement for JSX. It doesn't need tooling. And so they wanted to bring that kind of experience, language-centric templating. They wanted to bring it to Python, but hit this issue about scope.
Yeah. And it seems like it's just this obscure thing, but it isn't. You know, you use a nested function, it pops up. Use a generator expression, it pops up. Use a list comprehension, it pops up. So things that you might commonly want to use, now you need to know you shouldn't do that. So that's one thing. The second thing is it's slow. And it basically also breaks
a lot of optimizations that have
been introduced into Python in recent years.
So you don't want to do that either.
By using...
And the
creator of this hack, Barry said, don't use this hack.
Well, I mean, there are
good reasons to go and use sysgift frame, and especially there are historical good reasons.
But I think we have, again, so it's something that comes up because, you know, if you have dug into the internals of Python, you've looked at the inspect, you know you can do certain things.
And I think that's a fantastic way to explore new capabilities.
But it is not necessarily what you want to go rely on because,
again,
the thing I would have taught in the class, what is the difference between dynamic and lexical scope?
Well, here's where it really bites you.
This portion of Talk Python To Me is brought to you by Auth0.
Do you struggle with authentication?
Sure, you can start with usernames and passwords.
But what about single sign-on, social auth, integration with AI agents?
It can quickly become a major time sink.
And rarely is authentication your core business.
It's just table stakes that you got to get right before you can move on to building your actual product.
That's why you should consider Auth0.
Auth0 is an easy to implement, adaptable authentication and authorization platform.
Think easy user logins, social sign-on, multi-factor authentication, and robust role-based access control.
With over 30 different SDKs and quick starts, Auth0 scales with your product at every stage.
Auth0 lets you implement secure authentication and authorization for your preferred deployment environment.
You can use all of your favorite tools and frameworks, whether it's Flask, Django, FastAPI, or something else, to manage user logins, roles, and permissions.
Leave authentication to Auth0 so that you can start focusing on the features your users will love.
Auth0's latest innovation, Auth4Gen AI, which is now available in developer preview.
Secure your agentic apps and integrate with the Gen AI ecosystem using features like user authentication for AI agents, token vault, async authorization, and FGA for RAG.
So if you're a Python developer or data scientist looking for an easy and powerful way to secure your applications, Get started now with up to 25,000 monthly active users for free at talkpython.fm/auth0.
That's talkpython.fm/auth0.
The link is in your podcast player's show notes.
Thank you to Auth0 for supporting the show.
Let's talk about HTML templates because I know, Paul, that was a lot of your interest in this, right?
Indeed.
Michael, you and I are like web originals,
right?
You're a big fan of Chameleon.
Whenever you encounter a new web framework, the first thing you do is make a package for that that gives a
chameleon support.
That's right.
You want FastAPI, just put the FastAPI chameleon decorator on there and you're back to have proper language.
Yes.
But my feeling has been that Python web development, particularly templating, is stuck in the early 2000s.
I went and looked up recently.
I think Jinja was first released in 2008.
And there was a feeling back then that HTML and web design was something different than software.
Separation of concerns, but more importantly, separation of people.
You wanted to keep the templating people away from the software.
You've got your designers and you've got your developers and they exchanged
the CSS.
I'm going to give you this sandbox where you can't break things.
And it's going to be like Python, but not really Python.
And the world doesn't work that way anymore.
Front-end development is software.
In the JavaScript world, it's software.
It's components.
It's tooling.
It's testing.
It's all of these things where people expect powerful tooling as part of software.
We haven't.
And there have been some things starting to get into this area, but this was what I was originally interested in, what Jim and I had talked about quite a bit.
Dave comes from a similar background.
And we want, in a general sense, we want DSLs, domain-specific languages, that are closer to Python.
So when you say, here's a symbol, it's a symbol.
And you know the scoping rules because it's just Python.
It isn't some invented scoping rule.
And you can use your formatter on it.
And you can use mypy on it.
And you can use all blah, blah, blah.
You can get IDE assistance on it because it's just Python.
And so that, from an HTML perspective and a web perspective, we're trying to move from PSP, JSP, PHP-style templating as a separate non-Python concern over into this new world.
Dave, how did I do on that?
Do you buy what
I just said?
I absolutely buy it.
And like Paul mentioned, that's sort of how I came into this crazy rollercoaster ride, too, which is I had been working with a number of nonprofits over the last couple of years, building Python backends, doing a lot of front-end development with Python code.
and feeling like, and in particular, one of the projects I worked on a couple years ago used HTMX.
I think it was one of my first experiences with HTMX.
And for those who haven't used it, you often write big templates and then occasionally you need to send lots of little blobs of HTML back.
And it really starts to get difficult to use a tool like Jinja or a tool like Django templates to produce lots of little blobs of HTML while still keeping everything cleanly organized.
You end up with lots of sort of include statements or Jinja macros.
And those are great, powerful features, but they aren't quite as powerful as what Paul was saying, which is the full generality of the Python programming language to begin with.
And so, you know, we started resorting to using HTML builders like HTTPY in my case, but there are a few others, Dominic and others.
And those felt great, but they also felt to me like what building web stuff felt like in the JavaScript ecosystem circa 2010, right?
Before tag template strings came along and ultimately in the JavaScript world before JSX came along as well.
And so it did feel like there was really an opportunity to revisit that question.
And that's sort of how I found Jim and Paul, who were thinking about this stuff and have been thinking about this stuff for far longer than I in the Python ecosystem.
Yeah, very neat.
I pulled up an example from Vue.js.
And Dave, you mentioned HTMX.
And one of the big ideas that Carson Gross from HTMX promotes is locality of behavior.
Like I should be able to look kind of here on my editor and see all the stuff's going on.
There shouldn't be four different places and then a convention that pulls in a fifth place that then makes a thing happen.
And there's a lot of that in the JavaScript world of like, well, here's your behavior.
And literally, here's the fragment of HTML that we're going to work on with capturing values and different substitutions and stuff.
And it feels like new templating, and by templating, you're the one who said this silver letter, right?
Yeah.
New templating options like Chameleon 2 or Jinja 3 or whatever could come along and build on the ideas using some of the things here.
Yeah, absolutely.
And I'm really hoping we see an explosion of that as after Python 3.14 ships out the door.
So a lot of this work that the three of you plus others, I want to be super clear that there are other folks at the top of this PEP here.
Yes.
About this who have also put a lot of work into it.
Yeah, not just at the
top of the pep, but also, of course, the broader Python community in the discussions without which.
And then Paul mentioned the discussions are longer than for any pep.
But without that community feedback, I don't think we have landed
where we are now.
So if I print this, how long would this be?
How many pages?
206 pages to print the discussion of the TagStrings announcement.
And that was the first.
There were two discussions.
Even better
than Novella.
Yeah, that's incredible.
Also
great
feedback in other locations as well that we were also really trying to respond to.
They were talking about Reddit or Hacker News.
And a lot of credit to Jim on this.
in the first round, Jim was really about lazy evaluation.
And it was part of bigger ideas about inside out or outside in rendering and streaming and generators and a lot of things connected in his brain about it.
And there was a lot of practical pushback, including Astral, about, hey, we're going to struggle to statically analyze that for Ruff.
And Jim thought about it pretty hard and talked with Dave a lot and talked with others about
rolled that back. Wow. So there's a difference between, there's a difference here between lazy, which is they're evaluated eagerly, these t-strings, but maybe, and async, right? So can we do async stuff on our strings? Like you have to call a function given a template to render text. That seems like you could just write that, yeah?
Let me unmute myself. So yeah, I mean, the basic thing here is that these are expressions that can be evaluated, right? And so just because you have a, you know, I'll go for something that's even, you know, broader than this. You look at something like, you know, common pattern like Django's query set, right? So it's lazily evaluated until you actually go and actually look at its contents. A query doesn't even happen, right? In terms of against the underlying SQL engine that you're using.
And in any event, the point is that we can have laziness where we Lambda wrap it.
That was the original idea, and there's a lot of potential value in that.
But there's also this aspect that, in general, the Python community has come up with a number of ways to incorporate laziness.
And specifically through maybe it's an interval, Maybe it's a query set that is also inevitable.
Maybe it's through the use of async expressions.
These are all expressions that can be passed around and then used by, you know, something that is evaluating with respect to that.
So t-strings don't change any of that, right?
Because, you know, if you have that expression and it's been evaluated, but it's lazily, it's been lazily so, it can still be used for however you're going to work with that template in the function that operates on it.
And I think this is just going to get at most of the things that I was thinking about when we were originally looking at this from this more lazily done way without the typing issues that ultimately we decided would make it too difficult to work with.
So I think this is just something where we looked at what is the Python ecosystem?
How have we solved these problems?
and even though there was, you know, I really wanted to go and have something that basically would allow for maybe some greater functionality along, you know, doing like a deferred or lazy type capability implicitly, you know, that can be something else.
We can bring, you know, there are discussions around like bringing in macros.
It's, you know, you could implement that using coding on your file.
I don't know where that goes.
It might even interface with what we've done with t-strings.
But the important thing is that you don't have to bring all that in in order to go and benefit from what we're doing with this.
And
by
simplifying what we've done, I think we've, you know, come up with something that works a lot better. And I really valued the great feedback we had from the community as far as that was concerned.
Yeah, thanks. One of the things I hear a lot mentioned throughout the conversations and the PEP and stuff is DSLs. So a domain specific language and SQL is kind of a domain specific language. But I think a lot of times people are thinking something I make that is really simple, right? Maybe I want to make a language to talk to simple robots, right? And I want to use this to construct maybe a way to talk to it that's way simpler, but easier to parse because you can say, well, here's where the where piece went or whatever, right?
You can pull them out of the interpolations and the values and stuff.
Can you guys talk to maybe some examples of what you had in mind or what might be possible there?
This is good to me.
So the Python has been a very popular tool for constructing two types of DSLs.
One would be like the internal DSL that you see in Pydantic or SymPy, that sort of thing, where it's basically taking advantage of operator overloading.
So let's put that aside.
We'll look at the other version, which is this external DSL, where we think about, again, canonically HTML, SQL being pretty large targets.
But if you look at the PyParsing project, you'll see, I don't know, how many dozens of languages it supports.
Not to mention the fact that it's straightforward to write your own grammar in it and parse it into an abstract syntax tree.
Yeah, I mean, it's just like, as it says here, the use of parsing expression grammars, you know, really makes it very straightforward to write a cursor.
So I highly recommend anyone who's like interested in writing their own toy language or maybe have greater ambitions, look into tools like this, because I think this is one of the fantastic advantages we have in the Python community is we have really great libraries like this that are widely used.
And so for your example of writing something that would interface with a robot, absolutely, absolutely.
That's something that you could express.
And you think about, would that potentially be even something where it could be useful for education, for example?
And how would it work with, again, t-strings?
Well, again, you would basically say there's this domain of things that we know from the Python space.
We're computing maybe some velocity that we want the robot to move at.
We're computing which color of brick that we want to pick up or whatever it happens to be.
And we can basically say that that's something that's happening in our Python code directly.
And then there's this language that we're using to talk to the robot.
Okay. And what it looks like in terms of the t-strings is you basically are saying, okay, I'm going to go and parse this language fragment with some parser that can be made to use placeholders that will work with interpolations.
And I'm going to parse it. I'm going to get an abstract syntax tree out of that. I'm going to use that to then evaluate how I'm going to go and say, you know, send in a number or color or other information to that toy language or more ambitious language.
and then send out whatever is necessary in order to complete that communication with the system that's implementing that.
So it's going to be great for people who really love languages and want to play with them.
And again, I would start with something like PyParsing.
That was a great example of the type of tool you could use here.
Excellent.
Yeah, I'll put that link in the show notes so people can check it out.
Yeah, maybe bringing it all back home for a second or maybe just because I've got my head wrapped in building slide deck for a lightning introduction, lightning talk introduction to t-strings.
But, you know, a common use case here when you're writing code that takes a template is not returning a string, but as Jim is kind of deeply hinting at here, parsing and returning some kind of abstract syntax tree.
So in the HTML case, and you can actually find examples of this, for example, in the PEP 750 examples repository, there's an HTML function there and it has a bunch of nice features, but you're returning an HTML element back from the code that processes the T-string, you don't, in fact, have to grab a string out of a T-string right away or ever if you don't want to.
So there's an immense amount of flexibility here that we're excited to see people use.
Yeah. Dave, under your account on GitHub, Dave Peck.
Needs
to move.
You know what? It's fine. It's just as good as anywhere.
You have a bunch of examples of things you might do
with
these.
and one of them is HTML.
People can see how that might work and so on.
And what are some of the other notable ones in here?
I know I was looking through this earlier.
Well, we wanted to show some basic examples like, hey, t-strings have a syntax that looks a lot like f-strings.
How could you build f-strings on top of t-strings?
So there is an F paren-paren method that's implemented here that just kind of helps you understand, okay, I'm writing dynamic code to do the thing that f-strings would have done at compile time anyway.
We also have a structured logging example.
And I'm excited about this, you know, structured logging that Python has shipped a logging cookbook for a long time since the Python 2.something era.
And one of the examples in that logging cookbook is structured logging, by which we mean like, hey, I want to write out a sentence or two that people can understand, that humans can read.
But I also have some values that I'm substituting in that sentence.
And I'd really like that to be written out in some schema compliant way.
And with t-strings, you can kind of do that in a really elegant way, which is to say you write the T-string once, you send it to some kind of method that expects t-strings on logging, and it emits basically the equivalent of an F-string.
So that's the human readable bit.
And then maybe it uses JSON or something to emit a structured output to a different log stream entirely.
So one of the examples in the PEP and also in this PEP 750 repo is, you know, we send the human readable stuff to standard out and we send the machine readable stuff to standard error.
And you can imagine, you know, your logging system is going to redirect those somewhere else over
time.
Yeah.
I mean, the example here, you got standard error, but you could easily do a document database with JSON as well.
And then put an index on action and say, show me all the actions
taken
that have this commonality in it.
Right.
and do a querying, oh, bam, rather than really error-prone, like substring matching of text or whatever, right?
Yeah, and I'm really excited about it.
You write the T-string once, and you get the benefit of both the human readable and the structured schema-compliant output, and that's really exciting to me.
Yeah,
and I guess if you use Postgres, you could just put it in a JSON field as well.
Oh, yeah, we call that mullet
schema, right?
It's a business up front and partying back where the last column on every table is a JSON field.
I've never heard that.
That's incredible though.
It's like, yeah, we look real formal, but don't look back there.
Got it in the ponytail today.
Yeah.
Amazing.
Okay.
One thing I wanted to cover, there's a really interesting thing from somewhere in here.
I have pulled this up, I believe.
I'll just go to the PEP.
And the PEP, there's a section that talks about how to teach this.
And I think that that's, there's just a couple of ideas here that I think would make it really interesting for helping people understand better, right?
Speaking to developers or maybe people who build libraries like web frameworks or logging libraries or something.
Who wants to kind of give us a few of the ideas here that just maybe like, I know we touched on some of them a little bit.
Yeah, I mean, I'm happy that I kind of stepped through the basics here, which is, you know, we touched on the fact that the syntax of t-strings and f-strings is essentially identical.
Anytime you have an F, you can substitute with a T, but the result, the evaluated result is entirely different.
You get a string or a template, and we've kind of talked about all the reasons why you might want to do that.
I guess the key thing for developers to understand, and I'm going to divide developers into two groups here, those who use t-strings and pull in like an HTML or a SQL library, for example, and don't really think much about what's going on under the hood.
For them, all they need to know is, hey, you write T of something and you send it to your SQL library and it's safe.
And you don't really need to think much more about it than that.
And then, of course, we had, sorry, but we had things like literal strings and other stuff in the type system that kind of tried to make type checkers check and
catch when that would happen.
Right. But this is more runtime catching because of the way it operates rather than, hey, it's a bad idea to do that.
But, you know, Python typing can be ignored.
So,
yeah, it's probably worth mentioning the limits of that.
I mean, template and interpolation, which are new types that ship with Python 3.14, are ones that you can cons up at runtime directly.
You don't need to start with a literal.
And so you can, of course, as a developer, do all kinds of goofy stuff and cons up all sorts of malicious templates if you want to.
But generally speaking, if you're working from literals, which we sort of expect is the very common case, and you're using libraries that know about this new feature when Python 3.14 ships, generally speaking, you're staying on the safe side.
You're staying in the bright, well-lit path.
Yeah.
One of the ideas I like to think about in APIs and design of software is like falling into the pit of success or falling into the pit of despair.
You want to make it so the natural action is to fall into the pit of success and you've got to work your way out of there.
You know what I mean?
Yeah, you have to work hard to get there.
Yeah,
hopefully we've
found a nice balance there.
Yeah, it seems like it has.
Yeah, I
mean, I think from a teaching it perspective, you know, the pit of despair is so easy to fall into with f-strings, right?
You know, so your structure logging, you know, I'm sorry, using f-strings in your logging is like, oh, I inadvertently log some passwords.
Well, that's unfortunate, right?
Or I, you know, I'm using f-strings with a SQL statement.
It's like, oh, that really worked until it didn't.
And so it's very easy to go down that into that pit of despair as you're describing.
Whereas we're hopefully making it, you know, something where you have to work a little bit, know what you're doing, in fact, in order to go and actually do something that's bad.
So, you know, I'm sure that, you know, someone can show me, you know, a couple steps that, you know, make it straightforward to get into that pit of despair.
But I don't think it would be still the most obvious thing to do.
So from a teaching perspective, we want to ensure that the most obvious thing to do is the right thing to do.
And, you know, people can build libraries, you know, an HTML function or whatever in order to ensure that is, you know, going to work with that right path.
But there's more.
I think, Paul, you know, if you wanted to go and just how to teach this, I think part of this is just like, again, things like IDE integration and things like, you know, working with lenders and whatnot.
That's also very exciting in terms of what can be done.
And for me, that's kind of the exciting part.
but there's a side about really lowering the bar for writing these functions that handle a template.
You're not going to do anything with a template yourself.
You're going to hand it to a function that's going to do something.
And it's going to return a stringable, not a string, something that can be made later into a string.
But it's the people on the other side that are going to be creating the values and the content and all that kind of stuff.
And we have a real chance here to help them.
We're not going to talk about double curly braces or single curly braces for the rest of time.
It's single curly, just that alone.
And what goes in there isn't going to be some invented language with a pipe that you send to safe or whatever.
And you got to go memorize all these rules about how do I call a macro.
It's just Python, which then means IDEs and tools and linters and formatters and type checkers all get to play a game.
Go to mypy and file a ticket asking for type checking on Jinja.
There is a ticket already and you can see their comments.
They're not that interested.
Same thing for a lot of other tools.
But if they support 3.14, they support template strings and they support f-strings and they support this kind of everything because everything is just where it's supposed to be.
And if I can go a little bit, Dave, is it okay if I go a little bit further on this riff about tooling?
Let's see, you've got some points to make.
Sorry, I'm on a roll.
I'll try to wrap it up, I promise.
This idea of a big ecosystem of tooling and all of that will give us a developer experience that's competitive again.
All of these tools can start pitching in.
I'm with the PyCharm team.
Because this is f-strings with a T, they did it just like that.
Dave did a fork of black where he got T string support basically just like that because it was a T instead of an F.
Then we can get into some more interesting things like an HTML templating library.
We are very fortunate in the world of Python to have Andrea over from JavaScript on the PyScript team.
He's written 400,000 variations of JavaScript templating engines including tag template literals.
He
knows everything.
He contributed a lot to this PEP such as that alternating thing.
He's creating an HTML templating language that is browser first.
Michael, you had a Vue.js up earlier that had like at click.
There's going to be a lightning talk at PyCon about showing this in PyScript where something can run on the server and in the client and it's
nuts.
The whole thing is just...
Server rendered templates, but also client-side stuff.
Yeah, yeah,
yeah, yeah.
So there is a chance for us in the world of Python, it doesn't have to be our spelling, but if we can agree to structure and intermediate representations, Dave has ideas about how HTTPY could play ball.
They can make components that we can consume.
We can make components that they can consume.
I'm really bullish on how we can change the developer experience in web development and more to be modern Python with tooling.
Dave.
I'm here for it. I'm here for it, Paul.
Yeah, I'm just going to give you a what what here.
Yeah.
I think if we really can unlock a language that works well on the front end, I know PyScript's come a long way, but I feel like we need a view-like thing, right?
And
it sounds like
work is being done.
I mean,
if that comes along, there's going to be a lot of people that go, wait, we don't have to do JavaScript?
Are you serious here?
That would be pretty amazing.
Just throw in your 100K MicroPython implementation of PyScript and
go off
to the races.
Go ahead, Jim.
Yeah, I was just going to say, and one other nice thing about t-strings and the fact that they look a lot like f-strings is that it's going to be a straightforward thing for us to, or I shouldn't say for us, but I think the community.
I think there will be plenty of people who can work on this, fortunately, to incorporate t-strings into MicroPython.
And now you, instead of having something that requires a somewhat heavier download in terms of CPython on the client side with PyScript, you can use MicroPython for that.
I looked into it.
It looks straightforward.
I hope that we will see that development happen sooner than later.
So a lot of opportunities to go and mix together client side and server side in some really interesting and very cool ways going forward with this work.
What an interesting angle to say, we'll add t-strings to MicroPython.
Yep, and keep that.
So that
it round trips to the front end of the browser in an efficient way.
Yeah.
We've got a bunch of sprint days coming up with PyCon, so you never know.
Okay.
But Michael,
when you mentioned that MicroPython is about 100K, which to my ears as an old school web person sounds huge, but also really tiny these days.
Like when you build, when you do the default Next.js app install, which literally does nothing but ship a static looking page to you.
Although, of course, static includes a whole bundle of React and other stuff with Next.js these days.
That's about 130K.
And that doesn't include an implementation of Python.
Yeah.
It's
kind of amazing.
Yeah, and I think it's pretty comparable to other things.
I'm trying to poke around and find some examples.
But yeah, I think 100K is certainly doable on a CDN and so on.
It's a sweet spot.
Yeah.
Hey,
Michael, I got one for you.
And this is one that Jim and I started talking about and others piped in.
Kudai, who's also working on this project, is doing stuff in this field.
LLMs and code that needs to generate good LLM-generated results.
If you had a template language that was closer to the language of Python and could be analyzed as such, and all the LLM and RAG tricks that people are applying to not just get code, but to get good quality code.
Is this a moment where we could invent a web development story for Python that wasn't just cool because it was browser first?
It was cool because it anticipates AI and generated code.
You know, if you can infer types and things like that because you can look into the structure of the template.
Yeah.
and
know things and they are Python rules inside the curly braces instead of invented stuff, you might have a better shot at machinery.
Jim, what do you think?
You had a lot to say on this.
Yeah, I mean, I think a lot of people are looking at stuff around like in-context learning with how they work with prompts and everything.
I do think that if I'm going to send a bunch of examples to like some sort of, you know, a mini shot, but I guess a few number of shots learning, it would be really nice to do it in a very structured way and really have good support for that.
And so if you look at, you know, how people typically do this, well, they emit f-strings.
And I'm sure it works most of the time.
I just want it to work all the time.
And so I think, you know, having something that can, you know, taint that structure, maybe even do some interesting, you know, like there's some stuff around like DSPY or whatever.
I'm not certain actually how it's pronounced, but it basically does additional rounds of optimizing your in-context learning, prompting in general.
Having access to that structure might be very helpful for it.
Who knows?
I think that there's a lot of interesting opportunities in this space where we maintain this structure, we're able to reflect on it, And then use that for whatever sort of interaction we have with other systems.
And fundamentally, that's what this supports.
Because you have access to those Python structures.
You can figure out what that's supposed to be before you go and send it off to somewhere else.
So what does that mean in terms of capabilities?
It's very interesting.
Paul, when you were talking about typing earlier and then talking about mypy, it just made me realize or think, I guess I thought about it before, But reemphasize that for me, the typing is a communication tool to me, mostly through things like PyCharm, but not 100%, but mostly through the editor saying, here's what it's supposed to be here.
Here's what this is supposed to do.
So I don't have to go to definition and try to decipher it.
And I almost never use mypy or one of these PyRite or Pyre or, you know, you name it, because that's not my goal.
My goal is to add typing so that I can stay out of the docs, except when I really must.
And the same applies to what you share with chat and agenda code generators.
They can look at those types and they can see much more information and it can make them way more accurate and productive, right?
And I feel like this could communicate more information to them, like you were saying, so they have more structure to work with rather than just, here's a string, I don't know what it is.
Can I riff on that for a second?
Yes, riff.
This is all not news to Dave, who he and I are writing our lightning talks and FlaskCon talk together.
You're around on Friday afternoon.
Come see Dave.
Come see me.
It's going to be mind
-blowing.
Lightning talks are going to be mind-blowing, too.
Don't they normally publish those videos from FlaskCon as well?
I think they do.
Maybe.
He needs help.
Okay.
Well, I'm hoping.
Poor David is doing 500 jobs at once.
Everyone support David Lord.
I'm going to be giving a demo in PyCharm, at least, of T-String support with interpolation autocomplete and navigation and all the PyCharm tricks, but also a experimental plugin that does component support with TDOM.
So it looks just like JSX, where you pass props to something and it obeys the can do not just autocomplete of the props, But if you're missing a required prop, it will know that because it looks at the function signature of the component.
And it will match the types of the prop.
If you pass a string for an int, it will squiggle you.
In the future, we can go further like a lot of IDs can do and extract components to be standalone, to get big components into small components, all kinds of things.
Once you get into the world of tooling, you know, you've got typing, you've got signatures, you've got all of these great things.
mouse over for doc strings and doc hints and help.
Lots of help.
That's awesome.
Well, I'm looking forward to it.
Guys, we're about out of time.
I want to wrap this up with one final thought here.
So speaking to several audiences, let's say two audiences at the moment, give us some advice for potential adopters.
So if I'm Sebastian from FastAPI or David from FlaskCourt or I'm some other library adopter, SQL, MicroSQLAlchemy, right?
Or that's audience one.
Audience two would just be people who thought f-strings were awesome and this is even more awesome.
They want to try it in their code.
What are some pitfalls and best practices for these folks?
And what are the opportunities there?
Well, I mean, I think, you know, in general, the fact that t-strings exist doesn't mean that f-strings need to disappear tomorrow.
So I guess that would be the first thought I'd have for the community that isn't actively building libraries that might benefit from T string functionality, which is that the
tool is
still useful.
And in fact, there are many cases where probably what you really want is an f-string rather than a t-string.
It's exactly
these cases where you want the interpolations to do something special, whether that's prevent injunction vulnerabilities or, you know, transliterate, you know, a single dictionary into a bunch of attributes in HTML where you might want to start playing with t-strings.
And there, you know, I think if you're a library developer and you happen to be at PyCon, come say hello.
we'd love to talk to you and kind of figure out how you're thinking about adopting these.
I think the biggest one that came up in discussion amongst library developers that I saw was just, wait, how do I type my function?
So if I'm writing a SQL layer and I've got an execute method, right now that takes a string or maybe it takes, you know, Michael, you mentioned a little string.
It takes some variety of some special type that my library supports.
Should I also take a template there?
Should I allow a union of both?
Probably that's a foot gun.
you probably really want to think about separating these things out.
And so I think we'll see best practices like that kind of emerge over time.
Yeah, I would add a couple things.
One, we actually love f-strings.
When you
look at the actual code that implements the t-string functionality in terms of like a library, like an HTML function or whatever, what do you find in there?
Lots of uses of f-strings to actually go and pump out the actual string that you need.
It's just done in this, you know, disciplined fashion that we can do because we have carefully separated out when the interpolations are being actually evaluated in that context, right?
Second thing to think about is in terms of like a good best practice would be, you know, if you have a T-string, you know, and you say HTML, well, I don't think HTML should just like do something there or SQL or whatever.
It should go and allow it to prepare, you know, a document object model or, you know, prepare a SQL query or whatever.
And then you execute it or render it or whatever.
So I would differentiate this sort of setup versus, you know, some final rendering would be a typical best practice that certainly I would recommend.
And there are obviously more, you know, another best practice definitely is at some point, you probably want to think about the optimization of these things, right?
And so we really put in some thought into how the template strings can be used as a memorization key efficiently.
So you can look it up in terms of an LRU cache.
Now, this is no different than if you looked at the internals of, say, the RE module, you know, sports regular
expressions.
Yeah.
You know, there is this, at one point, you actually had to go into RE compile.
And it's not a bad practice to do it, but if you look internally at it, it actually does the RE compile for you.
So you don't pay the overhead of running through this Python parse every single time.
Interesting. I didn't know that.
Yeah.
But the actual implementation of that in terms of running the regular expression is done through this bytecode virtual machine that's specific to regular expressions.
and can be very efficient.
So again, we'll see some of these sorts of separations where we'll think about what it means to go and have a fast path where you actually are evaluating this HTML fragment or whatever, or working with SQL.
And then there's some sort of, well, you have to pay the parse penalty at some point.
But part of paying that parsing penalty is ensuring that things are done in a safe fashion, being written out in a structured way.
So that's, you know, more than makes up for it compared to, again, just, you know, just using f-strings and hoping that your SQL statement didn't include, you know, in that interpolation, the Bobby tables evil injection.
Yeah, excellent.
For me, I'd say first a shout out to our PEP sponsor and the hero for the second half of all this, Lissandros, has been marvelous.
getting the implementation and shaping in our interface to the rest of the core team and all that kind of stuff.
Really fast turnaround, really joy to work with.
Dave and Lissandro spent a lot of time ironing out all the little things.
I think about this whole path since Guido and Jim sat down at a PyCon like three years ago on the implementation.
I think it's been, this will be like the fourth PyCon since this whole thing first started.
And Jim and Guido kind of laid the groundwork for where we are right now, which is t-strings is just the start.
t-strings by itself ain't that much.
And I think, Jim, you made some decisions to intentionally defer to future PEPs some of the things.
Jim just said about these functions that don't immediately render.
They prepare an intermediate representation that might later render.
For me, that's my interest in this PyCon.
Let's build a community.
Let's build a community around interoperability so HTPy doesn't have to spell things our way, but we can talk to each other because we agree on a node interface or something like that for a DOM representation.
The front-end world has gotten great value out of pluggability.
The Vite system, for example, is a processing chain with a documented intermediate representation.
It's easy to write a plug-in to go grab that and hack on it.
You want to turn everything into a relative URL?
Write a little plug-in, put it in the chain, and you'll be handed something that lets you operate on things.
We can do something great together.
We don't all have to do the XKCD to invent a new standard to replace all the other standards.
We can still work with Jinja.
We could still work with HTTPY and some of these other things, and hopefully we'll see some of that at PyCon.
Awesome. Thank you, guys.
And we're specifically recording this on a time frame that hopefully...
Thank you so much, Michael.
If people are dutiful and on top of their listening, we'll listen to this right before they go to PyCon.
So I would like to encourage them to reach out to all of you and maybe go to some of the lightning talks.
And if they have ideas, participate.
Because now is the time.
Thanks, Michael, for doing this.
And we're excited to meet everybody at PyCon who's heading out that way.
Yeah.
Paul, you're welcome.
And you too, Dave.
Jim, Dave, and Paul, thank you all for being here.
See you later.
All
right.
Thanks for having us.
Thank you.
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, B-O-S-I-T.
And it's brought to you by Auth0.
Auth0 is an easy-to-implement, adaptable authentication and authorization platform.
Think easy user login, social sign-on, multi-factor authentication, and robust role-based access control.
With over 30 SDKs and quick starts, Auth0 scales with your product at every stage.
Get 25,000 monthly active users for free at talkpython.fm/auth0.
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.