[Python-Dev] Re: User extendable literal modifiers ?!
Guido van Rossum
Mon, 30 Sep 2002 10:33:41 -0400
> 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
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"
> 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/~guido/)