On 3/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > The comma and "as" have different precedence in your proposed except clause > than they currently do in the import statement. I think that can lead to > confusion. In particular, if someone is used to > > from foo import bar, baz as flurp > > I think they might expect that in this try/except statement: > > try: > something() > except E1, E2 as e > print "something bad happened" > > if E1 is raised, e will not be (re)bound, but if E2 is raised, then it will > be. I know Python is not as heavily an operator-oriented language as C or > Perl, but I think it makes sense to maintain the same relative binding > precedence between operators in different contexts wherever possible.
This is as good a point as any to explain that 'as' is not an operator. It's a piece of syntax. It behaves different in each context where it is used -- because the context determines what it does. The parallel you suggest simply doesn't make sense: 'as' in the import context causes a simple renaming, and the name should be different for each renamed module, of course. But 'as' in an except clause is not a renaming -- it simply separates the exception "matching pattern" from the variable that is to receive the exception *value*. Having different exceptions bind different variables doesn't make sense -- how would the code know which variable to use? > There seem to be other places where Python is beginning to require parens > even though they aren't strictly necessary to resolve syntactic ambiguity. In the style guide only, I hope. The parens that are mandatory in a few places *are* necessary to resolve ambiguity. > This might be one of them. No, the original proposal (which was already in PEP 3000 anyway) is fine. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com