Re: Other notes

[Steve Holden]

Bengt Richter wrote:
On Wed, 29 Dec 2004 13:11:43 -0500, Steve Holden <[EMAIL PROTECTED]> wrote:
[...]
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.
Good point, which I didn't address in my reply. (in fact I said I liked
@infix('..') for punctuation-char-named ops, but I was too busy with my
idea to think about that implementation ;-)
Well, that explains the lack of detail. I realize that you are more 
likely than most to be able to come up with an implementation.

Potentially, you could do it dynamically with a frame flag (to limit the damage)
which said, check all ops against a dict of overloads and infix definitions 
while
executing byte code for this frame. Of course, the compiler would have to defer
some kinds of syntax error 'til run time. I.e., '..' would have to be translated
to OP_POSSIBLE_CUSTOM_INFIX or such. I doubt if it would be worth doing.
Right. I can't say I think deferring syntax errors until runtime is a 
good idea.

OTOH, I think my suggestion might be ;-) I.e., just do a macro-like (not a 
general
macro capability for this!!) translation of expressions with dots at both ends 
and
no embedded spaces (intial thought, to make things easier) thus:
    x .expr. y =>  expr(x, y)
when expr is a simple name, you can use that expression format to call a 
two-arg function
of that name, e.g.,
    def interval(x, y): return xrange(x, y+1)
    for i in x .interval. y: print i,  # same as for i in interval(x, y): print 
i,
but you could also write stuff like
    def GE(x,y): return x is MY_INFINITY or x >= y
    if x .GE. y: print 'x is greater than y'
The .expr. as expression would allow module references or tapping into general
expression and attribute magic etc. I.e., (untested)
   from itertools import chain as CHAIN
   for k,v in d1.items() .CHAIN. d2.items(): print k, v
or if you had itertools imported and liked verbose infix spelling:
   for k,v in d1.items() .itertools.chain. d2.items(): print k, v
or define a hidden-attribute access operation using an object's dict
   def HATTR(obj, i):
       try: return vars(obj)[i]
       except KeyError: raise AttributeError('No such attribute: %r', i)
   if thing .HATTR. 2 == 'two': print 'well spelled'
or
   from rational import rat as RAT
   if x .RAT. y > 1 .RAT. 3: do_it()
or
   your turn ;-)
Well, I can see that Fortran programmers might appreciate it :-). And I 
suppose that the syntax is at least regular enough to be lexed with the 
current framework, give or take. It would lead to potential breakage due 
to the syntactic ambiguity between

        module .function. attribute
and
        module.function.attribute
though I don't honestly think that most people currently insert 
gratuitous spaces into attribute references.


[precedence and associativity]
My suggestion if implemented with left-right priority would be easy to
implement (I think ;-) And you could always override order with parens.
Now you're just trying to make it easy :-)
regards
 Steve
--
Steve Holden               http://www.holdenweb.com/
Python Web Programming  http://pydish.holdenweb.com/
Holden Web LLC      +1 703 861 4237  +1 800 494 3119
--
http://mail.python.org/mailman/listinfo/python-list