At 07:39 PM 4/10/2006 -0400, Blake Winton wrote: >Phillip J. Eby wrote: >>I tried doing something like this when I was writing RuleDispatch, and >>gave up in disgust because there's no sane way to implement "and" and >>"or" operations with this approach. The bitwise operators (&, |, and ~) >>bind too tightly to be used with comparison expressions, so doing >>something like "x>y & z" would mean "x>(y&z)" instead of "(x>y)&z". > >How would symbols, or ast access have helped you with that problem? Would >you really go around manually mangling the parse tree to move the "&" >higher in the branches somehow?
No - I'd have used 'and', 'or' and 'not': they're what I wanted to use in the first place. >What do you think about the oft-maligned curly brace? I think it should remain the syntax for dictionary literals, and not get involved here. >And it should be possible to tell the difference between it and a dict >with a bit of a lookahead... (Really it's the conflict with dict >initialization that I expect to kill this proposal.) For both implementation and readability reasons, Python syntax should require no more than 1 token of lookahead - by which I mean you should be able to parse it in purely token-by-token fashion without ever peeking ahead. _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
