https://github.com/darioteixeira/pgocaml

Note that the variables are safely and correctly interpolated at compile time. And it's type checked across the boundary too, by checking (at compile time) the column types with the live database.

Also:

    db.execute(t"QUERY WHERE name = {name}")

    db.execute(f"QUERY WHERE name = {name}")

I don't think this new format specifier is in any way applicable to SQL queries.

    sh(t"stat {some_file}")

I'd have to take a look at the order things happen in shell, but you might even be able to increase security/foot-gun-potential a little bit here by turning this into something like `stat "$( base64 -d [base64 encoded content of some_file] )"`.

    db.execute(f"QUERY WHERE name = {name}")

    db.execute(t"QUERY WHERE name = {name}")

  db.execute(f"QUERY WHERE name = {name}")

  db.execute("QUERY WHERE name = %s" % name, ())

https://xkcd.com/327/

I completely disagree with this. Look what happened to Log4J when it was given similar freedoms.

I understand why this seems strange at first!

As Paul mentioned, we spent quite a lot of time considering these issues as PEP 750 came together. In the end, we concluded (a) the PEP leaves open quite a few potential approaches for tools to adopt (not just the one you suggest, as others here have pointed out), and (b) it's ultimately something that the broader tooling community needs to rally around and should probably be out of scope for the PEP itself.

So, with that background in mind, I am indeed hopeful we'll see the ecosystem adapt! :-)

    html(t"<h1>Hello</h1>")

JavaScript's tagged template literals are actually about as flexible as this, since you can dynamically choose the tag function, it's just very rare to do so, so tools assume a lot based on the name of the function. Python tools can basically do the same thing, and just not support t-strings that aren't nested inside a well-named processing function.

But that's far from the only option, either! IntelliJ for Java also supports annotations on arguments [1] that then mean that you get syntax highlighting everywhere you use a string literal with the given function:

    public void query(@Language("SQL") String sql)

> If a library or tool encounters an annotation Annotated[T, x] and has no special logic for the metadata, it should ignore the metadata and simply treat the annotation as T. As such, Annotated can be useful for code that wants to use annotations for purposes outside Python’s static typing system.

So something like this should be perfectly viable:

    SQL = Annotated[Template, "language", "SQL"]
    
    def query(sql_query: SQL):
        # do stuff with Template to sanitize
    
    query(t"SELECT * FROM foo WHERE bar={bar}")

[0] https://www.jetbrains.com/help/pycharm/using-language-inject...

[1] https://www.jetbrains.com/help/idea/using-language-injection...

[2] https://docs.python.org/3/library/typing.html#typing.Annotat...

Not the only thing. You can also look at how it is used. Your editor could know of how some popular libraries use t-strings, track which t-strings get passed into functions from those libraries, and use that to assume what grammar the t-string should follow.

Is that cheating? In some sense, yes, but it also is useful and likely will be worth it for quite a few programmers.

Writing `query: SQL = t"SELECT ..."` is a small price to pay for such a DX boost.

Having more control over the interpolation of string values is a win IMO.

    db1 eval {INSERT INTO t1 VALUES(5,$bigstring)} 

EF/EF Core has existed for years :)

https://learn.microsoft.com/en-us/ef/core/querying/sql-queri...

It's far more essential than little utilities like textwrap or goliath packages like Python's bundled tkinter implementation.

This is especially noticeable with AWS Lambda where you can have a lot of useful stuff running for years without doing more than bumping the runtime version every year or two, but also that is one highly opinionated architecture so it’s not globally optimal for everyone.

;-)

    bar(t"zoop")

    import std/strformat
    let world = "planet"
    echo &"hello {world}"

In general, with user-defined operators and templates and macros, Nim has all kinds of Lisp-like facilities to extend the language, but with a more static focus which helps for both correctness and performance.

  sql"..."
  html"..."

    bar(“zoop”)

    print “foo” 

    print(“foo”)

I like F strings a lot, but for the most part I think all of the various X-strings should just be classes that take a string as an argument.

This is a very big deal! It's also about centralizing that work. Now that sanitization can occur in the consumer of the t-string (for example, the API to your HTML renderer), rather than in every f-string.

  >>> a, b, c, d = (lambda a, b=45, c=None, **d: (a, b, c, d))(**{'a': 234, 'xyz': 32456})

    >>> match {'b': 45, 'c': None}|{'a': 234, 'xyz': 32456}:
    >>>     case {'a': a, 'b': b, 'c': c, **d}: pass
    >>> print(a, b, c, d)
    234 45 None {'xyz': 32456}

I see each of these as distinct but overlapping; I'm (slowly) writing a guide to string formatting with all of these in mind, trying to emphasize when I'd choose one over the other. (fwiw I personally avoid % and + these days; $ is pretty uncommon in practice; f-, t-, and .format() all seem to have good unique uses.)

It's definitely true that those four string formatting techniques violate the "one obvious way" advice.

"Situation: There are 14 competing standards...." https://xkcd.com/927/

t-strings don't interact with anything else in the language; they, as you yourself pointed out, could almost be an isolated library. That makes them low impact.

This is also true syntactically; they're just another type of string, denoted by "t" instead of "f". That's easy to fit into one's existing model of the language.

Moreover, even semantically, from the point of view of most language users, they are equivalent to f-strings in every way, so there's nothing to learn, really. It's only the library writers who need to learn about them.

Then we have to consider the upsides - the potential to eliminate SQL and HTML injection attacks. The value/cost is so high the feature a no-brainer.

Other languages have a policy of prototyping such things out of core, and only adding it to the core language if it gains traction. Of course that works better if the language has a mechanism for extending the syntax out of core.

Meanwhile, pytest is still not part of the standard library.

I am wondering what is the reason behind not using a similar syntax to JavaScript? Seems simpler to me.

  # Compare this:
  template = t"<p>{evil}</p>"
  safe = html(template)

  # To this:
  safe = html"<p>{evil}</p>"

[1] https://peps.python.org/pep-0292/

In fact, the repo of a companion project from the author has the ticket that spawned the work leading to t-strings: https://github.com/jviide/htm.py/issues/11

As for variables and arbitrary code/lambdas, yes: t-strings can do that, just like f-strings

Also, in addition to the other SQL example using "?" to fill in the "holes" for parameters in an SQL friendly way, some DBs also support named parameters, so the "hole" in the string form might be naively replaced with something like `f"@{item.expression}"` and that also forms the key in a dict to pass as parameters. (You'd want to make sure that the expression inside the template is useful as a parameter name, and not something more exotic like {1 + 3} or {thing for thing in some_list}, in which cases you are probably auto-assigning some other parameter name.)

  def process_template(template: Template) -> tuple[str, tuple]:
    sql_parts = []
    args = []
    for item in template:
      if isinstance(item, str):
        sql_parts.append(item)
      else:
        sql_parts.append("?")
        args.append(process_value(item.value))
    return "".join(sql_parts), tuple(args)

Other replies gave examples of other use cases. But the neat thing about Python is that you don't need to "include this boilerplate" for the common cases. It can be wrapped up in a decorator (which could be included in `templatelib`). Or, as you say, in a method on the Template class.

I think I'd implement it as a generator, calling `process_value` (defaulting to `str`) on the Interpolations, so that the caller can still do more with the results (or just `''.join` them).

But these are separate considerations; nothing prevents implementing them later, or indeed adding them to the implementation before the 3.14 release.

I actually quite like the simplicity of this design over tagged literals in JS.

This sounds like unnecessary fluff in what was supposed to be a simple language. I'm worried Python is turning into C++42 with 65535 ways to do one simple thing.

Why not just:

    f'SELECT * FROM `{esc(table)}` WHERE name = "{esc(name)}"'

But yes, the PEP leaves open an important question: how will tools decide to work with common types of content in t-strings, like HTML or SQL?

There are simple approaches that can be taken in the short term (content sniffing) and more robust approaches (type annotations, perhaps) that will take time and the broader tooling community to develop.

As an example, I was excited about using `Annotated` on the function to indicate the language it expected. Turns out, a lot of linters know nothing about the type system.

    from sql import sql

    query = sql"SELECT user_id, user_name FROM {user_table_versioned} WHERE user_name = {user_name}"

The concept of prefixes itself feels a little deviant from readable code that is close to human language -- which is the spirit of Python

No

> They are just a special case of t strings.

Not really, because they produce a string right away instead of a template.

I honestly feel like a lot of people just seem bored and looking for stuff to be mad about.

    f"foo is {foo} and {bar=}"
    "foo is {} and bar={}".format(foo, bar)

t-strings are actually not strings, but Template objects, giving access to both the templating string and the parameters for processing. Sibling comments describe it as a custom .format implementation in that sense - it's f-string-like sugar where you're also allowed to take control of the .format function that it's sugar for.

    log.debug(f"The value of counter was {counter}, the nonce was {nonce}")

    log.debug(t"The value of counter was {counter}, the nonce was {nonce}")

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")

    some_call(f"unsafe dynamically created string")

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.