there is already work underway somewhere for a backport of strings.Template for python versions older than 3.14
if there isn’t, if anyone has advice on how to make that happen.
I am working on ibis, which is a dataframe API that generates and then executes SQL on various underlying SQL engines. In this recent issue, I think I came across a good use case for strings.Template. But, I want to make this available to users who aren’t using 3.14+.
So, I was wondering if there was a backport for these older python versions, and then we could make ibis accept either implementation (probably using a Protocol for the type hints).
I’m pretty sure you’re not referring to the string.Template class, which has been around for a very long time and needs no backporting. Are you asking about string.templatelib which is new in Python 3.14?
Template strings are a new feature in Python 3.14 (not yet released). As such, it won’t be backported by us to a previous version. It might be possible to use tricks à la future-fstrings to do so, but this would be a third-party endeavour. I’m not aware of anyone else who has asked about doing this yet.
I am also interested in potential backports since for production use we would not default to Python 3.14 for at least another 6 months to a year. It’ll be cool to see how Ibis make use of it for SQL templating
@NickCrews Perhaps the title of this post could be edited for clarity, to mention one or all of t-strings, Template strings and PEP750 rather than string.Template. It is defintely unfortunate the naming is confusingly similar…
Regarding the naming of this thread, yes it appears I chose a bad name, but I think I’m not allowed to change it now .
@sfermigier and I have done a few more tweaks to abilian/tstrings-backport, so now (please file an issue if not) that package is a drop in replacement for the stdlib implementation. That’s what I am going to use whenever I need a backport. I chose that over mkzeender/future-tstrings because I didn’t like the magicalness of transpiling the syntax at import time.
Here is the PR for how I’m trying to bring this into ibis if you are curious . Note that for these tests I just vendored in the entire tstrings implementation from that backport in order to avoid a new dependency for ibis. So if you are doing something similar, that seemed to work pretty well since it’s just a single file.
I’ve filed a couple of issues. There’s at least one gap that I spotted first time I looked.
Semi-relatedly:
Hopefully we should also get t-strings into the next Cython release. Because that goes through our own parser it’ll work on any Python version that we support. Although obviously compiling to a binary extension module is a fairly heavy step just to get backported t-strings so I’m not promoting it as the first choice.
As part of that we’ll monkey-patch our own implementation of Template and Interpolation into string.templates. One thing I’m keen to ensure is that we just use the generic interface. So if someone has monkey-patched an alternate implementation first then we’ll respect that and just use their classes.
Hi, I am the author of mkzeender/future-tstrings Feel free to ask me anything, or suggest improvements to the library. You can also open github issues if you want. I will release a stable version shortly after the python 314 release date.
.