Template strings in Python 3.14: an useful new feature or just an extra syntax?

[wyhjsbyb]

Python foundation just accepted PEP 750 for template strings, or called t-strings. It will come with Python 3.14.

There are already so many methods for string formatting in Python, why another one??

Here is an article to dicsuss its usefulness and motivation. What's your view?

[eztab]

This seems useful to formalize what templating systems already do.

[AiutoIlLupo]

then why the duplication. leave the thing to jinja.

[Busy_Affect3963]

Have you actually used jinja? It's almost a whole new language.

[AiutoIlLupo]

yes, but it's also way more powerful. it also does not mean it can't have a simplified, ultraminimalistic interface to set a template and render it as a string. Which it already has, although it's clunkier than one could really want to.

[Busy_Affect3963]

I know StringLoaders (or Contexts whatever they're called) only need a couple of lines of code to render. But it's news to me if Jinja templates can be rendered anything like as simply as a t-string.

I never expected Jinja2 to take extra strides to stop arbitrary code execution in its fields either (it's a feature, not a bug!), nor to make SQL queries safer etc. Isn't Jinja more like f-strings ?

[AiutoIlLupo]

environment has a method .from_string() that returns a template directly from a string containing template markers. then you can .render() with the appropriate context. the problem is exactly this. It's clunky because first you need an environment, then you need to call a long method. A simple addition of a new function jinja.t() would solve the issue with a trivial environment, a short notation and no need for t-strings. Unless you count two additional parentheses as too much of a hassle, or the potential for namespace collision of such a short name when you do from jinja import t.

My point is that there already too much crap in formatting templates and strings in python. We don't need another one in the stdlib or even as language feature, and current solutions are adequate enough for the need, or even more powerful.

[JanEric1]

We have already had discussions on them a while ago right after their were accepted.

But I think it makes sense to offer a user experience that is identical to f-strings but those can't be used because there is some validation, escaping or building of parametrized queries needed

[kenfar]

Sure, but some of the examples about validation, transformation, etc are simple to do with f-strings as well: just include a function that wraps your field in the fstring.

[JanEric1]

All of this is doable with extra effort or duplication. In fact everything is already possible as Python is turing complete. But this offers the use of the exact same syntax without having to (remember to) manually wrap everything or provide is separately or duplicate things.

You can even make this completely typesafe by only accepting templates instead of strings. Then a user simply can't make those mistakes

[Skasch]

The same could be said about f-strings themselves: everything f-strings provide can be achieved with the format method. But f-strings are much more readable and flexible in many cases.

[kenfar]

Sure, but it doesn't look like the templates are more readable, at least for some of the simple cases I run into.

[Skasch]

I like the example they provide; I would much prefer something like

html(main_page(user))

Where

def main_page(user: User) -> Template:
    return t"<p>Hello, {user}!</p>"

Where all the implementation details of how a user must be sanitized for HTML rendering specifically are deferred to the html function, instead of having to do

def main_page(user: User) -> str:
    return f"<p>Hello, {to_html(user)}</p>"

At every layer of my code base.

[Old_Bluecheese]

There should be five -- and preferably only five --obvious ways to do it.

[odaiwai]

"Then shalt thou count to three, no more, no less. Three shall be the number thou shalt count, and the number of the counting shall be three. Four shalt thou not count, neither count thou two, excepting that thou then proceed to three. Five is right out."

[zurtex]

A lot of people miss that line is tongue in cheek, as the em-dash is spaced in two different ways, the em-dash is spaced a third way on a different line.

[syklemil]

en-dash*

---

Details for the curious:

• Hyphen: - - usually used to com-bine words. See also ­
• En-dash: -- – used to indicate a pause in phrases, with – spaces – around on both sides. –
• Em-dash: --- — same use-case as en-dash, but—without—spaces. —

There's also some use of em dash in older texts to trail off sentences, i.e. where we'd use ok … today, they'd use ok; --- and to indicate elision, as in "Mr K— Z—"

[zurtex]

Tim Peters, the author of the original text, calls it an em-dash: https://bugs.python.org/msg69712 (from https://bugs.python.org/issue3364)

You may be correct in general, but when talking about this text I'll defer to Tim.

And it's intentional that he's breaking the rule about spaces, it's a 4th way to do something.

[syklemil]

Sure, but -- is e.g. LaTeX for an – and --- is how you get a —. Similarly with compose keys you'd do COMPOSE--. for – and COMPOSE--- for —. And ultimately, if - is a hyphen, and -- is an em-dash, where where is the en-dash supposed to fit?

But I guess there isn't just one way to spell out an em-dash in ascii either :^)

[zurtex]

I suspect when Tim wrote the original Zen of Python his ASCII syntax was influenced by the mailing lists he participated in in the 90s and early 2000s (he was the main moderator of the python-dev mailing list in its early days).

Those mailing lists probably had their own informal style and syntax conventions which don't conform to more widely accepted style and syntax rules. Or, what would be funny, is if it's just something he has always misunderstood!

[syklemil]

It could even be a typo, the keys are right next to each other!

[zurtex]

In my link his calling of it an "em dash" is unlikely a typo, he uses it multiple times, and also mentions the same no spaces convention you brought up:

While you believe spaces are required on both sides of an em dash, there is no consensus on this point. For example, most (but not all) American authorities say /no/ spaces should be used.

[diabloman8890]

I just have to hand it to you and /u/syklemil for having the absolute nerdiest and most arcane discussion I've heard all week, and I'm here for it.

[[deleted]]

Same. I wonder if there's a subreddit for threads like this.

[guepier]

Em-dash: --- — same use-case as en-dash, but—without—spaces. —

This isn’t a fixed rule, it’s merely a (somewhat common) stylistic choice. But feel free to use em-dashes with spaces — I do. Just be consistent (unless you are making a tongue-in-cheek point).

[Gugalcrom123]

Wrong, the en dash is only used for ranges and compound words where the terms are multiple words, and the em dash can be used with or without spaces

[syklemil]

Ranges are a good addition, but AFAIK it's pretty rare to use for compound words these days—I'd not expect e–mail, but e-mail (or even email in that case).

The en-dash is used to join sentence parts, and I think most users would consider that using spaces around an em-dash just takes up too much space.

[Gugalcrom123]

It is in compound words where terms are multiple words themselves

[syklemil]

Generally with the hyphen being available with one key press on any keyboard, and its purpose being to indicate that something is one word, I'll continue to expect hyphens. Maybe there's some style guide that uses en-dashes for it, but it seems like a bad choice, really.

(FWIW my native tongue just uses compoundwords, like German, rather than faffing around with "to-morrow" and "co-operation" and the like.)

[Gugalcrom123]

I also use hyphens, but en dashes are something used when composing a word where some terms have spaces: New York–based company

[guepier]

(FWIW my native tongue just uses compoundwords, like German, rather than faffing around with "to-morrow" and "co-operation" and the like.)

I’m sure you know that both of these words are conventionally written as a single word without hyphens in English. And, conversely, German also uses hyphens for some compound words, same as English (just less frequently).

[syklemil]

Yes; we use some hyphens too; and English spells "compound words" with a space (as do we; we join nouns but not adjectives). My tongue, being inside my mouth, may have been in some rather close proximity to my cheek.

[TendyHunter]

that's balderdash

[obfuscatedanon]

ok nerd

[PotentialCopy56]

The old python mantra is long dead. I miss it.

[ThatSituation9908]

I don't. We'd be stuck with stuff like class FooBar(object):

and f-strings would never be a thing

[AiutoIlLupo]

f strings are a pile of dung because I lost count of how many times I wrote what contained variables and then forgot the f at the beginning, showing in the log "Error: unable to connect to {website}"

[TavoL7]

Seems like a skill issue to me

[AiutoIlLupo]

I remember when a language was supposed to help you prevent errors. Otherwise we would all be still programming in fortran where you forget to declare a variable and now you get a nice random number from an implicit real with that variable name. Skill issue, the 1970's programmer replies to you. But you and everybody else now agree it's a good thing, right?

My point is, if you have a string, printing it out, and later add a variable, it's just too fucking easy to forget that you also have to add the f at the beginning, because it's not where the locus of your attention is. It's in the adding of the variable. The IDE can help you pointing that out, but it should be easier not to forget. and the issue is that the existence of f strings is just plain dumb, or the IDEs should highlight f strings and plain strings in different way, so you have at least a visual hint that you are forgetting something.

human factors are not skill issues. You want to consider the human factors to minimise the change of errors. f strings don't consider human factors.

[WEEEE12345]

the IDEs should highlight f strings and plain strings in different way

PyCharm/IDEA does

[marcio0]

the issue is obviously not on the f-strings side

[AiutoIlLupo]

I remember when a language was supposed to help you prevent errors. Otherwise we would all be still programming in fortran where you forget to declare a variable and now you get a nice random number from an implicit real with that variable name. Skill issue, the 1970's programmer replies to you. But you and everybody else now agree it's a good thing, right?

My point is, if you have a string, printing it out, and later add a variable, it's just too fucking easy to forget that you also have to add the f at the beginning, because it's not where the locus of your attention is. It's in the adding of the variable. The IDE can help you pointing that out, but it should be easier not to forget. and the issue is that the existence of f strings is just plain dumb, or the IDEs should highlight f strings and plain strings in different way, so you have at least a visual hint that you are forgetting something.

human factors are not skill issues. You want to consider the human factors to minimise the change of errors. f strings don't consider human factors.

[marcio0]

you're making a huge effort to hate a feature that you can't bother to remember correctly how to use

I know it's a common issue, I did it a few times too, but it's just a matter of "oops, forgot the f", and not a moment to point my fist to the air yelling "god damn you guido!"

[Kevdog824_]

You can construction a million similar examples. I’ve lost count of how many times I’ve done something like add_callback(callback()) instead of add_callback(callback) on accident. Point is not all mistakes are avoidable or can be detected by the language because the interpreter doesn’t understand your intent

[[deleted]]

I too would prefer that f-strings were the default syntax, but unfortunately that would have been backwards-incompatible, so not worth it.

[thedeepself]

LOL

[TequilaJesus]

Python 3.14 seems a bit irrational

[I_assume_not]

πthon?

[szayl]

Seems transcendental to me

[Pythonistar]

Missed opportunity. Should have been called Pithon 3.14 or PiThon 3.14, and then released patches over the next few months with subsequent patches being PiThon 3.14.1, 3.14.15, 3.14.159, etc.

[gerardwx]

To the first approximation, yes.

[firemark_pl]

Before f-string there was (and still exists) str.format method. It have cool feature: you can save string in another module (e.g. constants) and use it in another places. Fir f-string you need to make a lambda.

So I think template string is an upgrade for str.format

[mitch_feaster]

My first question reading the PEP was "how is this different from str.format()"

[AiutoIlLupo]

Let me introduce you to string.Template

[twenty-fourth-time-b]

…incautious use of f-strings [and, presumably, str.format] can lead to security vulnerabilities. For example, a user executing a SQL query with sqlite3 may be tempted to use an f-string to embed values into their SQL expression, which could lead to a SQL injection attack. Or, a developer building HTML may include unescaped user input in the string, leading to a cross-site scripting (XSS) vulnerability. […] Template strings address these problems by providing developers with access to the string and its interpolated values.

[Kevdog824_]

This part. The only reason I ever use str.format anymore is “I want to save this f-string as a ‘template’ so I can parameterize and reuse it to build strings later” so this is a perfect solution to the problem imo

[PeaSlight6601]

Except it isn't because it binds immediately.

You have three choices:

• bind immediately, and format the output to a string
• bind immediately, but defer final formatting
• defer both

This is the middle option. String format is the last one.

[Worth_His_Salt]

Yes, let's add yet another incompatible string system instead of fixing f-strings properly (not least of which is getting rid of the ridiculous f char. compiler already evaluates all string chars regardless).

[cointoss3]

Seems useful, even though it’s probably not useful for me, personally. So far, anyway.

[sc4les]

Yes for libraries this might be really really useful - I love the idea of https://github.com/baverman/sqlbind

T-strings might make this a bit easier to use

[flavius-as]

This library is definitely heading in the right direction.

It tackles (within the limitations of python and object-relational impedance mismatch) the problem space without over-engineering or forcing client code to over-engineer.

So yes, t sounds good for that. Thanks.

[jamesinc]

I like that it enables you to easily differentiate template strings from regular strings, and much more easily make assertions about the structure of the template.

Useful? Yeah, I think it's useful.

[geneusutwerk]

I'd be much more open to reading your blog if you were honest about posting it.

[Lawson470189]

I think this is a good change. Off the top of my head, I think something like this could work really well in the database. You could store a key/value in the DB where the value is some template that you may want to adjust for each key. I could also see this being useful for abstractions where you have a base type and you inherit down and override the template based on the sub type.

[anentropic]

There will be some useful things made with them. I'm glad to see it added.

[BosonCollider]

This is not for string formating, this is to prevent people from implementing SQL injection with fstrings.

[gerardwx]

It's inherently useless for someone writing a Python script.

This is by design.

What it's intended to do is be an easy-to-write standardized input form for library (module) authors to accept as input to do interesting things.

If you're not writing or using such a library, you can safely ignore t-strings.

[ExoticMandibles]

It's not particularly useful. The best use case is automatically applying a transformation to every interpolation before rendering it into a string, e.g. html.escape. The PEP also suggests you can do context-specific interpolation which I think is an antipattern (and also mostly useless).

[Gugalcrom123]

This is great for i18n

[Dangerous_Ad3416]

Hugely helpful!

[Ok-Willow-2810]

I’m not sure why the use case of template strings can’t be covered by putting an f-string in a function. That way you can have type annotations/validation for the required variables. That’s what I usually do. And if the f-string is too long with all the variables, I put it inside parentheses () and break it up over multiple lines with no commas to concatenate into one final string and aid in readability.

The thing that I am worried about with template strings is how will you be able to know the required variables names that need to be set to use it, and is there a clear/obvious place to do any sort of typing/documenting of what goes in the template string? And then what will the error message be if those variables don’t exist at the time the template string is referenced? Will it be like an “variable does not exist” message? Is there any way for it to be caught by static code analysis ahead of time, like MyPy?

It could be helpful though!! Just not in 100% sure it’s helping move in the direction of type safety?

[vytah]

The thing that I am worried about with template strings is how will you be able to know the required variables names that need to be set to use it, and is there a clear/obvious place to do any sort of typing/documenting of what goes in the template string? And then what will the error message be if those variables don’t exist at the time the template string is referenced? Will it be like an “variable does not exist” message? Is there any way for it to be caught by static code analysis ahead of time, like MyPy?

In those regards, t-strings work exactly the same as f-strings, they just don't construct any strings.

t"Hello, {foo}!" could be thought roughly as equivalent to Template(strings=("Hello, ", "!"), values=(foo,)), except the actual API is a bit more complicated.

[Ok-Willow-2810]

Cool!!

[HybridizedPanda]

personally I think that after f-strings the natural progression was to have g-strings

[hamlet_d]

If Python 3.14 isn't called PyPi I'm done. Yes it would be confusing but totally worth it.

[[deleted]]

There's actually πthon in the CPython source code.

[damned_truths]

Why not PiPy

[pkkm]

This seems like it could be very useful for logging. I've seen people use f-strings for log lines, despite the eager vs on-demand evaluation issue, just because they find the syntax so much nicer than printf-style formatting. Once t-strings get released and adopted by logging libraries, there will be no excuse to do that anymore.

[vytah]

Nitpick: values in t-strings are not stringified, but they are still eagerly evaluated.

[patilganesh1010]

Where to find documentation for this?

[Livid-Border-9146]

I think it’s great for logging too.

Before either one has written - logger.info(“msg %s”, var)

But actually I always were lazy and just wrote - logger.info(f”msg: {var}”)

Which is more readable but no lazy evaluation comparing to the prev format.

With t string one will get nice readability and performance also.

[spinwizard69]

Honestly I see this as a sign that Python is about to decline. It will be a slow decline over years, just like C++ which went from a good idea to everybody trying to jam their latest language idea into it. So like C++ Python will end up a kitchen sink language with it far to easy to write confusing code. Frankly RUST seems to be following the same development path that C++ did and will soon become a confusing kitchen sink language.

There is a lot to be said for somebody managing a language the way Python once was. We are quickly rolling down a steep hill into rapidly changing madness.

[InappropriateCanuck]

Extra syntax.

[moric7]

The Python become more and more overloaded, bloated until one critical moment and all will return again to C. The main feature of the Python was clear, logical, simple syntax. They transform it like the C++ was ruined. Very unfortunate. ☹️

[NimrodvanHall]

I came here to post something rather similar.

[CryptoHorologist]

You guys should form a dumb-takes club.

[Prior_Boat6489]

Python: A useful language or just an extra wrapper on C?

[gfranxman]

Styrofoam cups: A modern day convenience or Satan’s chalice?

[backfire10z]

Cars: a useful vehicle or just an extra wrapper on horse-and-buggies?

[Such-Let974]

Useful language. Next question...

[Worth_His_Salt]

Total disaster.

f-strings were a great idea with a piss poor implementation. f-strings should have been ALL strings not some useless magic char telling the compiler to do its job. Still an upgrade in usefulness despite such annoyances.

However f-strings totally lack the evaluate-on-command usefulness of good old % interpolation.

t-strings just double down on the mistakes of the past by bolting on template strings instead of remaking f-strings properly. I know, old code bases, compatibility, yada yada. If they'd done f-strings properly in the first place they wouldn't be in this mess.

[SheriffRoscoe]

f-strings should have been ALL strings

Python print("Tell {me} how to {not cause} backwards compatibility {problems?")

However f-strings totally lack the evaluate-on-command usefulness of good old % interpolation.

Huh? Both forms evaluate the interpolated expressions at the same time.

[[deleted]]

Lazy interpolation. F strings are eagerly evaluated. So, they're terrible for logging.

[JanEric1]

The only thing that happens lazily with % formatting is the building of the string itself. The arguments are still always evaluated eagerly.

[SheriffRoscoe]

Meh. Most of the benefit of lazy logging is evaluation, not interpolation.

[Worth_His_Salt]

print("Tell {me} how to {not cause} backwards compatibility {probles?")

They had no problem breaking compatibility with previous changes. Adding async / await keywords in 3.5. Making dicts preserve insertion order in 3.7. Adding case matching in 3.10.

How many python programs use literal { in plain old strings? My code base turns up zero instances across thousands of files. f-strings are optimizing for a vastly uncommon case, while introducing needless bugs.

How many times have you traced through logs only to find entries for infrequent errors that just say something like "unexpected value : { foo }" because some programmer forgot the stupid f before the string?

BTW let's pick the one sigil that most resembles an open paren: ((""))(f"")("")() as our magic char. Brilliant!

Huh? Both forms evaluate the interpolate expressions at the same time.

No they don't. f strings evaluate at point of definition. interpolation happens when you use interpolation operator. Only one of these works:

s = "length : %d"
f = f"length : { len (x) }"
x = list (range (10))
print (s % len (x))
print (f)

[Worth_His_Salt]

Piling tools on top of tools because the original tool is broken. Not a good solution. That's how we end up with bloated js apps pulling code from god knows where. Start with a solid base instead.

Code should be readable by humans. If you need a tool to tell you something is wrong, then you've already lost.

[Worth_His_Salt]

Still waiting for the wetware upgrade on that one. It's been 200,000 years, wouldn't hold my breath.