On Fri, Sep 27, 2002 at 12:03:17PM +0100, Gareth McCaughan wrote:
- Rational numbers. $r"123/234"
- Regular expressions. $/"foo.*bar"
- Dates and times. $t"2002-09-27 11:38"
- Hostnames and ports. $h"www.google.com:80"
Of course, if you have no shame , each of these but $/ can be written with today's syntax in no more characters, placing the type identifier first and then an arbitrary, existing operator second: r+"123/234" This, in turn, saves only one character over r("123/234")
Here's an example I wrote for work: class Dimension: ...
class DimensionMaker: def __call__(self, v): return Dimension(v)
def __add__(self, v): return Dimension(v)
D = DimensionMaker() I don't know if we'll ultimately judge the D+"..." syntax justified, given that it feels yucky and saves only one character.
Note that we're also treading very close to allowing function calls without parens, if we allow an arbitrary identifier before string literals. What actually happens if you write trailer: test | '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME in the grammar and change the compiler accordingly? I guess the problem becomes that '(' could be the beginning of a testlist from inside atom, but if you could arrange for '(' here to always start an arglist instead, or invent a new production "altpower" trailer: altpower | '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME altpower: altatom trailer* altatom: NAME | NUMBER | STRING+ Now, a x.y.z()[:] becomes legal syntax (and would be a call to 'a' with one arg, x.y.z()[:])
Likewise, D"123/234" becomes legal, and is equivalent to D("123/234"). you have a problem with anything now recognized as a prefix of a string, so r"123/234" can't work as $r"123/234" is proposed to work. Of course, you could make R 123/234 work, since that'd be (R 123)/234 which would be R(123)/234.
Personally, I think all of this is pretty ugly.