Most active commenters
  • Smithalicious(3)

←back to thread

620 points tambourine_man | 12 comments | | HN request time: 0.949s | source | bottom
1. Smithalicious ◴[] No.43750764[source]
I really was on the side of being generally willing to accept new python features, but this is getting ridiculous. What an utterly pointless thing to bloat the language with. At this point my moving to clojure as my first line language of choice is only accelerating.

This is of the category "things I wouldn't want to use even for the specific hyper niche things they're intended for". What even does a "t-string" represent? Because it's clearly not a string of any kind, it's a weird kind of function call notation. The programmer sees something that looks like string formatting, but the program executes some arbitrary procedure that might not return a string whatsoever.

replies(2): >>43751148 #>>43751503 #
2. nhumrich ◴[] No.43751148[source]
For me, this is the best feature to land in python for 6 years. JS has had this and it allows my code to be completely safe from SQL injection, which is an absolutely incredible feature, given SQL injection has been the #1 vulnerability for a long time.
replies(3): >>43754773 #>>43755585 #>>43755797 #
3. sanderjd ◴[] No.43751503[source]
The "bloat" is that you can now put the letter "t" in front of a string, rather than "f" or "r"?
replies(3): >>43751644 #>>43752948 #>>43755543 #
4. ◴[] No.43751644[source]
replies(1): >>43751712 #
5. ◴[] No.43751712{3}[source]
6. kccqzy ◴[] No.43752948[source]
I'm not the OP but I'm guessing with OP moving to Clojure that the bloat is basically any special syntax or special language feature that basically boils down to a function call or a let statement. A lot of functional programming languages have minimalistic expression syntax and they are just as expressive as OP needs them to be.
7. pauleveritt ◴[] No.43754773[source]
Thanks Nick for this response and all the time you've spent explaining. It's funny, I looked back at the comments on f-strings before they landed. They also got similar complaints about bloat. And yet, my uneducated guess: very popular.
8. Smithalicious ◴[] No.43755543[source]
It's a pattern moreso than this specific feature. There's an important qualitative distinction for me between something that's on the level of a library (even if it's the stdlib) on the one hand and first class features (ie things that require parser level support) on the other.

Python has historically been very conservative about this but in recent years has had one controversial language extension after another, while parts of the language that actually need love are left to languish IMO.

I wanna be very clear that this is me changing my mind -- I was (still am) very on board with the highly controversial assignment expressions ("walrus operator") for instance.

I don't have much faith about what the Python language will look like if you project the current rate of changes forward 10, 15, 20 years. It really doesn't help that I consider this new thing an active antifeature.

replies(1): >>43756666 #
9. Smithalicious ◴[] No.43755585[source]
But this doesn't prevent SQL injection, does it? It adds a grammar feature that you can then use to build SQL injection prevention following a novel idiom. Someone still needs to write the actual SQL building logic somewhere!

I don't think this is the right idiom for doing this. Frankly I don't think SQL query generation should look like string templating at all!

The sell seems to be "now you can write code that looks like an SQL injection vulnerability, without it actually being vulnerable!". I'd rather write code that isn't a vulnerability, and doesn't look like one, and doesn't have to bend the language grammar either.

replies(1): >>43775276 #
10. stefan_ ◴[] No.43755797[source]
What? Maybe in 2005. This is just strictly worse than parameterized because now you are also wasting time "escaping" strings which perpetuates the whole mixing data & query thing nobody even wants anymore.

It's like even the one case identified nobody has even thought all the way through. Now your SQL library only accepts t-strings, I get an obscure error passing in a simple static query. Ah yes, put the useless t on it. That sorted, now the SQL library escapes all the parameters it wasn't previously doing, to then hand the final unique query to the actual underlying SQL library which would much rather have the parameterized one so it can cache parsing. Jesus.

11. sanderjd ◴[] No.43756666{3}[source]
I feel like this is begging the question... This t-string feature is only controversial inasmuch as comments like yours here are criticizing it as being controversial...
12. calfuris ◴[] No.43775276{3}[source]
I'd rephrase the sell as "now people who are used to doing the wrong thing and risking vulnerabilities can do the right thing without any extra effort," with a footnote about the difference in types allowing libraries to force the change.