Python’s new t-strings

Sure, this avoids issues with SQL injections. However, I have a hard time imagining any developer who would both make such fundamental errors with f-strings currently and also switching to this option when it ships.

Seems like a self selection which renders this meaningless, to some extent :/

> However, I have a hard time imagining any developer who would both make such fundamental errors with f-strings currently and also switching to this option when it ships.

t-strings are a different type (both static and dynamic), f-strings are not. So t-strings can be mandated at the API level, forcing the developer into "proper" usage.

That is, you need third-party tools to differentiate between

    some_call("safe literal string")

and

    some_call(f"unsafe dynamically created string")

That is not the case when it comes to t-strings, `some_call` can typecheck internally that it got a t-string, and reject regular strings entirely.

Although some space probably needs to be made for composing t-strings together in case of e.g. runtime variation in items or their count. Facetting for instance. I don't know if that's a native affordance of t-strings.

But that would require any SQL library you're currently using to make the breaking change of no longer allowing strings.

sqlalchemy doesn’t really accepts strings - if you do, you need to pass them into a “conn.execute(text(…))”, so end users should not face a breaking change.

Yep. Probably worth it. You could also do this with a monkeypatch method to "opt in" to this change.

Yes?

Eventually, you won't be able to pass a string into the commonly-used DB libraries.

Yes. That's exactly what will happen, over time.