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...@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-le...@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/WHOPY26QUG46ONHLH5Q42F56HN6DHOIX/ > 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
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/P7A37Q7BVC4XF2YO5MZ4QU4YRMT7IJWO/ Code of Conduct: http://python.org/psf/codeofconduct/
