Other notes

[Steve Holden]

Mike Meyer wrote:

> bearophileHUGS at lycos.com 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