←back to thread

Python’s new t-strings

(davepeck.org)
620 points tambourine_man | 2 comments | 21 Apr 25 04:31 UTC | HN request time: 0s | source
Show context
serbuvlad ◴[21 Apr 25 09:51 UTC] No.43750075[source]▶
All things considered, this is pretty cool. Basically, this replaces

    db.execute("QUERY WHERE name = ?", (name,))
with

    db.execute(t"QUERY WHERE name = {name}")
Does the benefit from this syntactic sugar outweigh the added complexity of a new language feature? I think it does in this case for two reasons:

1. Allowing library developers to do whatever they want with {} expansions is a good thing, and will probably spawn some good uses.

2. Generalizing template syntax across a language, so that all libraries solve this problem in the same way, is probably a good thing.

replies(12): >>43750226 #>>43750250 #>>43750260 #>>43750279 #>>43750513 #>>43750750 #>>43752117 #>>43752173 #>>43752293 #>>43754738 #>>43756560 #>>43763190 #
rwmj ◴[21 Apr 25 11:03 UTC] No.43750513[source]▶
I did a safe OCaml implementation of this about 20 years ago, the latest version being here:

https://github.com/darioteixeira/pgocaml

Note that the variables are safely and correctly interpolated at compile time. And it's type checked across the boundary too, by checking (at compile time) the column types with the live database.

replies(1): >>43750774 #
tasuki ◴[21 Apr 25 11:39 UTC] No.43750774[source]▶
Yes, what you did is strictly more powerful than what the Python people did. And you did it 20 years ago. Well done, have an upvote. And yet, here we are in 2025 with Python popularity growing unstoppably and (approximately) no one caring about OCaml (and all the other languages better than Python). It makes me sad.
replies(3): >>43751186 #>>43751601 #>>43755054 #
skeledrew ◴[21 Apr 25 18:39 UTC] No.43755054{3}[source]▶
It's interesting how the majority has explicitly chosen NOT to use the "better" languages. Is the majority really that bad in their judgment? Or is it that "better" is actually defined by adoption over time?
replies(3): >>43755431 #>>43756148 #>>43757638 #
daedrdev ◴[21 Apr 25 19:16 UTC] No.43755431{4}[source]▶
It's clearly better in their opinion, they just aren't optimizing for the same metrics that you are. Python is better because it's easy for people to learn, imo.
replies(1): >>43755740 #
throwawaymaths ◴[21 Apr 25 19:50 UTC] No.43755740{5}[source]▶
its not easy to learn. its a challenge even getting it installed and running. what even is a venv? how do you explain that to a beginner?

python is popular because its what teachers teach.

replies(6): >>43756172 #>>43756692 #>>43756781 #>>43756970 #>>43757280 #>>43758584 #
psunavy03 ◴[21 Apr 25 22:38 UTC] No.43757280{6}[source]▶
If someone is challenged figuring out a venv and they're not an absolute beginner, perhaps they aren't cut out to work in technology. There are countless subjects in the field more challenging and complicated to wrap one's brain around.

Also, in 2025, just use uv.

replies(1): >>43761676 #
1. throwawaymaths ◴[22 Apr 25 13:11 UTC] No.43761676{7}[source]▶
> they're not an absolute beginner

gp's claim is not "its easy to learn". It's not just the concept -- it's the ergonomics, absolutely terrible footguns (especially when dealing with global wheels that can screw up your running system), and the hidden state.

replies(1): >>43764144 #
2. psunavy03 ◴[22 Apr 25 16:54 UTC] No.43764144[source]▶
When would you want to interface between a specific project and the global Python environment running your system? If there's ever a time when "lock the project into a venv and don't cross-contaminate its dependencies with the global Python environment" isn't the answer, that sounds like a corner case. Let each project be its thing by itself.