Steve Holden <[EMAIL PROTECTED]> writes:
> Mike Meyer wrote:
>
>> Steve Holden <[EMAIL PROTECTED]> writes:
>>
> [...]
>>>
>>>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.
>> By modifying the parsers grammer at runtime. After all, it's just a
>> data structure that's internal to the compiler.
>>
> But the parser executes before the compiled program runs, was my
> point. What strange mixture of compilation and interpretation are you
> going to use so the parser actually understands that ".." (say) is an
> operator before the operator definition has been executed?
Ok, current decorators won't do. Clearly, any support for adding infix
operators is going to require compiler support.
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
