Mike Meyer wrote:
[EMAIL PROTECTED] writes:
@infix
def interval(x, y): return range(x, y+1) # 2 parameters needed
This may allow:
assert 5 interval 9 == interval(5,9)
I don't like the idea of turning words into operators. I'd much rather
see something like:
@infix('..')
def interval(x, y):
return range(x, y + 1)
assert 5 .. 9 == interval(5, 10)
This would also allow us to start working on doing away with the magic
method names for current operators, which I think would be an
improvement.
Well, perhaps you can explain how a change that's made at run time
(calling the decorator) can affect the parser's compile time behavior,
then. At the moment, IIRC, the only way Python code can affect the
parser's behavior is in the __future__ module, which must be imported at
the very head of a module.
As others have pointed out, you do need to do something about operator
precedence. For existing operators, that's easy - they keep their
precedence. For new operators, it's harder.
Clearly you'd need some mechanism to specify preference, either
relatively or absolutely. I seem to remember Algol 68 allowed this.
You also need to worry about binding order. At the very least, you
can specify that all new operators bind left to right. But that might
not be what you want.
Associativity and precedence will also have to affect the parsing of the
code, of course. Overall this would be a very ambitious change.
regards
Steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC +1 703 861 4237 +1 800 94 3119
--
http://mail.python.org/mailman/listinfo/python-list
