7 ms·
f-strings won’t sanitize the value, so it’s not safe. The article talks about this.
by burky 1y ago
f-strings won’t sanitize the value, so it’s not safe. The article talks about this.
- Tenoke 1y agoThe article talked about it but the example here just assumes they'll be there.
- sanderjd 1y agoWhat do you mean by "they"? You mean the template interpolation functions? Yes, the idea is that by having this in the language, library authors will write these implementations for use cases where they are appropriate.
- Tenoke 1y agoThe sanitization. Just using a t-string in your old db.execute doesn't imply anything safer is going on than before.
- masklinn 1y agoUsing a t-string in a db.execute which is not compatible with t-strings will result in an error. Using a t-string in a db-execute which is, should be as safe as using external parameters. And using a non-t-string in that context should (eventually) be rejected.
- Tenoke 1y agoAgain, just because a function accepts a t string it doesn't mean there's sanitization going on by default.
- tikhonj 1y agoYes, but if a function accepts a template (which is a different type of object from a string!), either it is doing sanitization, or it explicitly implemented template support without doing sanitization—hard to do by accident! The key point here is that a "t-string" isn't a string at all, it's a new kind of literal that's reusing string syntax to create Template objects. That's what makes this new feature fundamentally different from f-strings. Since it's a new type of object, libraries that accept strings will either have to handle it explicitly or raise a TypeError at runtime.
- Tenoke 1y agoI'm not sure why you think it's harder to use them without sanitization - there is nothing inherent about checking the value in it, it's just a nice use. You might have implemented the t-string to save the value or log it better or something and not even have thought to check or escape anything and definitely not everything (just how people forget to do that elsewhere).
- sanderjd 1y agoI really think you're misunderstanding the feature. If a method has a signature like: class DB: def execute(query: Template): ... It would be weird for the implementation to just concatenate everything in the template together into a string without doing any processing of the template parameters. If you wanted an unprocessed string, you would just have the parameter be a string.
- Tenoke 1y agoI'm not. Again, you might be processing the variable for logging or saving or passing elsewhere as well or many other reasons unrelated to sanitization.
- nemetroid 1y agoSure, and the safe() function proposed upthread might also just be doing logging.
- Ukv 1y agoThe original comment said that it'd replace db.execute("QUERY WHERE name = ?", (name,)) with db.execute(t"QUERY WHERE name = {name}") It's true that in theory `db.execute` could ignore semantics and concatenate together the template and variables to make a string without doing any sanitisation, but isn't the same true of the syntax it was claimed to replace? Just because templates (or the previous syntax of passing in variables separately) could be used in a way that's equivalent safety-wise to an f-string by a poorly designed library does not mean that they add nothing over an f-string in general - they move the interpolation into db.execute where it can do its own sanitization and, realistically, sqlite3 and other libraries explicitly updated to take these will use it to do proper sanitization.
- nemetroid 1y agoYour "old" db.execute (which presumably accepts a regular old string) would not accept a t-string, because it's not a string. In the original example, it's a new db.execute.
- masklinn 1y agoBecause t-strings don't create strings, so if the library doesn't support t-strings the call can just error.