3 ms·

One place we landed with PEP 750 is that Template instances have no natural string rendering. That is, you must process a Template in some way to get a useful

One place we landed with PEP 750 is that Template instances have no natural string rendering. That is, you must process a Template in some way to get a useful string out the other side. This is why Template.__str__() is spec'd to be the same as Template.__repr__(). If you want to render a Template like an f-string for some reason, the pep750 examples repo contains an implementation of an `f(template: Template) -> str` method: https://github.com/davepeck/pep750-examples/blob/main/pep/fstring.py https://github.com/davepeck/pep750-examples/blob/main/pep/fs... This could be revisited, for instance to add `Template.format()` in the future.

unsnap_biceps 2y ago
I totally agree with `Template.__str__()` == `Template.__repr__()`, but I would strongly be for adding a `Template.format()`. I expect that over time I'll be passed template strings where I expected normal strings and adding that example `f(template: Template)` everywhere to my code bases is just a lot of repeated code for no real value. That said, I think this is a great bit of work and I look forward to getting to use it! Thank you!
- zahlman 2y ago
  > and adding that example `f(template: Template)` everywhere to my code bases is just a lot of repeated code for no real value. I'd agree that it should be somewhere within the library, even if it's just a separate top-level function in the described `string.templatelib`. If it isn't, I'm sure someone will make a PyPI package for it right away.