5 ms·

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 cur

• masklinn 1y ago
  > 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.
  • Timwi 1y ago
    But that would require any SQL library you're currently using to make the breaking change of no longer allowing strings.
    • baggiponte 1y ago
      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.
    • nhumrich 1y ago
      Yep. Probably worth it. You could also do this with a monkeypatch method to "opt in" to this change.
    • masklinn 1y ago
      Yes?
    • sanderjd 1y ago
      Yes. That's exactly what will happen, over time.
• sanderjd 1y ago
  Eventually, you won't be able to pass a string into the commonly-used DB libraries.