4 ms·

Reread my comment. It’s about noticing you have an “f” or a “t” and both are very similar characters.

• rocha 1y ago
  Yes, but you will get an error since string and templates are different types and have different interfaces.
  • Izkata 1y ago
    Click "parent" a few times and look at the code example that started this thread. It's using the same function in a way that can't distinguish whether the user intentionally used a string (including an f-string) and a t-string.
    • zahlman 1y ago
      Yes, and the parent is misguided. As was pointed out in multiple replies, the library can distinguish whether an ordinary string or a t-string is passed because the t-string is not a string instance, but instead creates a separate library type. A user who mistakenly uses an f prefix instead of a t prefix will, with a properly designed library, encounter a `TypeError` at runtime (or a warning earlier, given type annotations and a checker), not SQL injection.
      • Izkata 1y ago
        In this particular instance it can't, because there are 3 ways in question here, and it can't distinguish between correct intentional usage and accidental usage of an f-string instead of a t-string: db.execute("SELECT foo FROM bar;") db.execute(f"SELECT foo FROM bar WHERE id = {foo_id};") db.execute(t"SELECT foo FROM bar WHERE id = {foo_id};") The first and second look identical to execute() because all it sees is a string. But the second one is wrong, a hard-to-see typo of the third. If f-strings didn't exist there'd be no issue because it could distinguish by type as you say. But we have an incorrect SQL-injection-prone usage here that can't be distinguished by type from the correct plain string usage.
        • Timon3 1y ago
          There is no reason to support the first or second usage. It's totally fine to always require a t-string: db.execute(t"SELECT foo FROM bar;") See? No reason to accept strings, it's absolutely fine to always error if a string is passed.
          • Izkata 1y ago
            My (and their) point is that's the already existing API. You're proposing a big breaking change, with how many frameworks and tutorials are built on top of that.
            • Timon3 1y ago
              It's not like this is the first time APIs have been improved. There are many tools (e.g. deprecation warnings & hints in editors, linter rules) that can help bridge the gap - even if t-strings are only used for new or refactored code, it's still a big improvement! There's also simply no hard requirement to overload an `execute` function. We have options beyond "no templates at all" and "execute takes templates and strings", for example by introducing a separate function. Why does perfect have to be the enemy of good here?