[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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4