←back to thread

Python’s new t-strings

(davepeck.org)
620 points tambourine_man | 3 comments | 21 Apr 25 04:31 UTC | HN request time: 0s | source
Show context
enescakir ◴[21 Apr 25 07:32 UTC] No.43749266[source]▶
Not sure about introducing yet another string prefix. Between f-strings, raw strings, and i18n stuff, it’s already getting crowded. Curious how readable this will be in large codebases.
replies(3): >>43749334 #>>43749489 #>>43749515 #
wodenokoto ◴[21 Apr 25 07:46 UTC] No.43749334[source]▶
I'm of the opposite opinion. Let's set the prefixes free!

    from sql import sql

    query = sql"SELECT user_id, user_name FROM {user_table_versioned} WHERE user_name = {user_name}"
replies(4): >>43749474 #>>43749545 #>>43749548 #>>43749927 #
dmurray ◴[21 Apr 25 08:12 UTC] No.43749474[source]▶
How would this be different from a function sql() that operates on one of these new t-strings?

The syntactic sugar of changing it from sql(t"...") doesn't seem particularly valuable. The novel thing about t-strings is that they change the parsing at compile-time.

replies(3): >>43749506 #>>43749648 #>>43749903 #
stavros ◴[21 Apr 25 08:18 UTC] No.43749506[source]▶
It wouldn't be different, but it would be more convenient because we no longer have to count the number of %s, you'd put the variable inline.
replies(1): >>43749558 #
1. masklinn ◴[21 Apr 25 08:28 UTC] No.43749558[source]▶
That's... already the case of t-strings?
replies(1): >>43749570 #
2. stavros ◴[21 Apr 25 08:31 UTC] No.43749570[source]▶
Yes, that's my point. The GP was already talking about a t-string.
replies(1): >>43749609 #
3. masklinn ◴[21 Apr 25 08:37 UTC] No.43749609[source]▶
dmurray was comparing a hypothetical sql"..." with sql(t"..."). There are no %s either way.