There may well be use cases for this, but one thing struck me. From the PEP: "Template Literals provide an easy way to access the local and global variables (like f-strings), so that passing a dictionary to the Template is not necessary." This seems to be crossing the line between "data" and "code" -- that's a line that can get pretty fuzzy in Python, but it's still a distinction I find helpful to think about. f-strings provide an easy way to build strings with stuff stored in code: local variables. This makes them very helpful for things like building Exception messages and the like, or showing the results of computation. But for the most part, populating a template is likely to be done from data, rather than code -- results of a database query, or what have you. So this kind of template building is usually very well suited to passing a dictionary around, rather than using the local namespace. Even if you are using Python objects to model your data (e.g. dataclasses and the like) -- you still have: a) one object to pass in to your template builder and/or b) an easy way to make a dict out of the object to pass into a template. I could be missing something, but I just don't see the benefits of having f-string like access to local variables in this context. -CHB On Thu, Jun 10, 2021 at 8:56 AM Stephen J. Turnbull < turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Thomas Güttler writes:
This really helps developers to avoid cross-site-scripting attacks by enabling a secure escaping of all strings which are not explicitly marked as safe.
Frameworks can already do this by unconditionally applying a function like conditional_escape to all evaluated template variables. (If that's too drastic for your taste, there could be a pragma %conditional_escape_everything to turn it on.) Why don't they? If it's not "they just didn't think of it", and there's a real reason, why doesn't that reason apply to your template literals?
Note that str has no "safe" attribute, and attributes defined by a framework are not known to Python. You need to explain how you can Python-evaluate an expression to a str as your template literal does, and still preserve the "safe" mark that I presume is an attribute of a class defined by the framework.
I guess the problem of accessing the framework's attribute can be solved by delegating that to the __format__ method of the framework type, and maybe preserving it can be handled by having that __format__ method return a subclass of str.
But this reintroduces a strong possibility of programmer error, because any function that constructs and returns a new str will strip the "safe" mark. This happens *before* the __format__ method can be invoked -- str's __format__ does not check for a safe mark -- so it's a real problem. This might dramatically reduce the utility of these template literals because it's simply not safe to allow the full range of expressions that f-strings allow. (That could be a YAGNI, but you need to explain and if possible document that.) Also, this means that frameworks can no longer just inherit from str: they need to reimplement literally every method that returns str, or prohibit its use in templates.
Note that 'is_literal' is not the same as "safe". Based on the example, this is intentional: is_literal simply means that this isn't the value of an expression, simplifying implementation of the internal function that evaluates the template string to a TemplateLiteral. But this means that the function joining a TemplateLiteral needs to consider both is_literal (which is safe but apparently unmarked) and the 'safe' attribute. This seems more complicated than it needs to be.
TemplateLiteral is not a good name for that type. The backtick construct is a literal (except it's really not ;-), the TemplateLiteral is a constructed value. TemplateValue or TemplateTokenSequence or something like that might be a better name. In any case it's a little confusing that both the syntax and the value are called "literal". It's not impossible to understand, but at least for me I have to think "is this the syntax or is this an object?" every time I see it.
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/WHOPY2... Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython