[Python-Dev] Re: User extendable literal modifiers ?!
Fri, 27 Sep 2002 08:43:38 -0500
On Fri, Sep 27, 2002 at 12:03:17PM +0100, Gareth McCaughan wrote:
> Possible applications:
> - 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:
This, in turn, saves only one character over
Here's an example I wrote for work:
class Dimension: ...
def __call__(self, v):
def __add__(self, 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+
becomes legal syntax (and would be a call to 'a' with one arg,
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
Personally, I think all of this is pretty ugly.