After skimming through the posts in this thread, and mulling over this PEP for a little while I think it’s time to offer my 2 cents.
I have one big issue here, which is both a gripe and a suggestion.
The syntax should be foo(t'bar'), not foo'bar'. It follows that rather than a *args pack, the function foo should accept one argument, of some new built-in type that’s instantiated whenever t'bar' is encountered (and contains the information that would have been in the *args pack), but I don’t think that should be controversial.
(Replace t with some other fixed prefix if you wish, I’m not here to bikeshed that.)
Python’s existing string prefixes - b'', r'', f'', and some I don’t know about - give a far greater difference in functionality than replacing what is ultimately one variable name with another. b'' creates bytes rather than str. r'' changes the handling of backslashes. f'' interpolates variables. Tag strings are one specific piece of functionality, they should have one specific prefix.
I see several clear and significant benefits to the foo(t'bar') syntax:
- Python keeps open its opportunities for the future to add new string prefixes.
- It is a simpler and more obvious syntax: you want to call
foopassing some special string expression, so write a function call tofoo(foo(...)) passing a special string expression (t'...'). - The function responsible for interpreting the tag string can take additional arguments, which may well come in useful if the function author wants to allow callers to use those additional arguments to affect how the interpreting is done. (Indeed, the
t'...'expression alone could be used anywhere, not just as a function argument, but that’s besides the point.)
On the other hand, I cannot see any reason why the proposed foo'bar' syntax carries any benefit, other than saving 3 characters.
Hopefully this can be taken into consideration. To me, it’s a no-brainer to have t'...' just create an object of a particular type that can be used like any other Python object; am I alone in this thinking?