isn't the whole idea that with a special syntax, you can do some of the processing when compiling the script? it's pretty pointless to invent more ways to call functions with string literals as arguments...
Not necessarily. Domain-specific notations are useful with or without compile-time processing, and sometimes the added noise of the function call syntax + string literals can get in the way of readability.
(Hey, binary operators are [mostly] just another syntax for calling functions, and around here we all agree that they're a good thing. :-)
That said, I'm not very enamored of the $x"foo" notation -- too much line noise. MAL's original minimalistic proposal (123x, or pehaps also 123.456x, and maybe even 1.23e-456x) seems cleaner in cases where it's applicable. I don't expect Python will ever grow date/time or (heaven forbid) IP address literals, and we already have r"regex" literals.
btw, the following note is slightly related to this topic, and has been generating some buzz lately (at least in my mailbox):
That looks interesting in a futuristic kind of way. I'm curious why you decided not to return fixed-type tuples of the form (tag, attrs, content) -- that seems easier to deal with than having to deal with both (tag, content) and (tag, attrs, content). Tuples used as records ought to have a fixed lay-out.
Parsing this would be tricky -- the tokenizer would have to know in what state the parser is in order to tell when to switch to XML if it sees a '<'. And if you want to use a standard XML parser you'd have to be careful to stop reading after the final '>'.
And what can this do that you can't do by putting it in a string literal and feeding it to a convenience function?
--Guido van Rossum (home page: http://www.python.org/%7Eguido/)