[Python-Dev] Re: User extendable literal modifiers ?!

[Guido van Rossum]

[effbot]
> 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):
> 
>     http://effbot.org/zone/idea-xml-literal.htm

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/~guido/)