Re: [Python-Dev] Py3k: Except clause syntax
Tristan Seligmann wrote: Greg Ewing [EMAIL PROTECTED] [2006-03-21 13:20:53 +1200]: Gareth McCaughan wrote: def f((x0,y0) as p0, (x1,y1) as p1): For maximal utility, this would affect the calling signature of the function, too: it would now have keyword arguments named p0 and p1. I still think it hurts readability of the header too much to be worth the benefit. To me it would seem much clearer all round to write def f(p0, p1): x0, y0 = p0 x1, y1 = p1 -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
Skip There seem to be other places where Python is beginning to require Skip parens even though they aren't strictly necessary to resolve Skip syntactic ambiguity. Guido In the style guide only, I hope. Alex Technically, I believe the first place where this did not apply Alex was list comprehensions, ... This was the instance I was thinking of, but it was far enough back that I didn't remember if it was for readability or disambiguation. Skip ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
[EMAIL PROTECTED] wrote: Skip There seem to be other places where Python is beginning to require Skip parens even though they aren't strictly necessary to resolve Skip syntactic ambiguity. Guido In the style guide only, I hope. Alex Technically, I believe the first place where this did not apply Alex was list comprehensions, ... This was the instance I was thinking of, but it was far enough back that I didn't remember if it was for readability or disambiguation. There is also the cases of types needing parens such as tuple((1,2,3)). The same is true for dict, list, and sets. They could have been written to accept individual items, (not a suggestion as it is slower), so requiring tuples, sets, and/or sequences where they are used as such isn't unexpected. But as long as I can do the following I will be happy. some_exc_group = (some_except, some_except, some_except) try: ... except excgroup as value: ... Cheers, Ron ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
Guido van Rossum wrote: In the style guide only, I hope. The parens that are mandatory in a few places *are* necessary to resolve ambiguity. That's not entirely true. My original list comprehension implementation didn't require parens around unpacked loop variables -- Guido added them because he thought it looked better that way. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
Gareth McCaughan wrote: but wouldn't if be nice if you could say def f((x0,y0) as p0, (x1,y1) as p1): I'm not sure that it would. Currently you can look at a function header and get a picture of its calling signature, but this would clutter it up with implementation details of the function that aren't relevant to the caller. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
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
Re: [Python-Dev] Py3k: Except clause syntax
On Mar 19, 2006, at 7:42 PM, Guido van Rossum wrote: ... 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. Technically, I believe the first place where this did not apply was list comprehensions, back in 2.2, since (for example) [x, y for y, x in whatever] could have been syntactically disambiguated but (quite reasonably, IMHO) [(x,y) for y,x in whatever] was mandated instead. Alex ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
On Friday 2006-03-17 05:04, Alex Martelli wrote: Hmmm, if we allowed '(expr as var)' for generic expr's we'd make a lot of people pining for 'assignment as an expression' very happy, wouldn't we...? I hope not. It looks a lot more like a binding construct than an assigning one. But what about pattern-matching? Currently, you can say def f((x0,y0), (x1,y1)): ... but wouldn't if be nice if you could say def f((x0,y0) as p0, (x1,y1) as p1): ... and have both the packed and unpacked forms available? (Prior art: some functional languages that let you define a function with multiple pattern-matching clauses have a similar feature.) -- g ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
Hello, what about: try: something except NameError or OtherError as e: Only a thought. -- bye by Wolfgang ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
Nick Coghlan wrote: So, as a somewhat novel approach, what about putting the as *before* the list of exceptions types? -1. When you're scanning down a series of except clauses, what you're looking for foremost is the types of exceptions being caught. The bound name is of secondary importance and only relevant to the code in the except clause. Greg ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
Wolfgang Langner wrote: try: something except NameError or OtherError as e: I don't see that this really helps anything, since it's no clearer how or and as should bind than it is how , and as should bind. Also it has the disadvantage that except E1 or E2 as e: would *not* be equivalent to except (E1 or E2) as e: On the other hand, in except E1, E2 as e: the E1, E2 is just a tuple expression, so it's exactly equivalent to except (E1, E2) as e: Greg ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
Greg On the other hand, in Gregexcept E1, E2 as e: Greg the E1, E2 is just a tuple expression, so it's Greg exactly equivalent to Gregexcept (E1, E2) as e: 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. There seem to be other places where Python is beginning to require parens even though they aren't strictly necessary to resolve syntactic ambiguity. This might be one of them. Skip ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
[EMAIL PROTECTED] writes: Greg except type as value: Baptiste except type with value: Can I catch multiple exceptions with a single value in this case? Today, I write: try: foo() except (TypeError, KeyError), msg: print msg Either of the above seem like they'd require me to repeat the value, e.g: try: foo() except TypeError with msg, KeyError with msg: print msg Not very Pythonic methinks. except TypeError or KeyError as msg: ! not-serious-ly y'rs, mwh -- That's why the smartest companies use Common Lisp, but lie about it so all their competitors think Lisp is slow and C++ is fast. (This rumor has, however, gotten a little out of hand. :) -- Erik Naggum, comp.lang.lisp ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
Michael Hudson wrote: [EMAIL PROTECTED] writes: Greg except type as value: Baptiste except type with value: Can I catch multiple exceptions with a single value in this case? Today, I write: try: foo() except (TypeError, KeyError), msg: print msg Either of the above seem like they'd require me to repeat the value, e.g: try: foo() except TypeError with msg, KeyError with msg: print msg Not very Pythonic methinks. Wasn't the proposal : try: something except NameError, OtherError as e: something... ? With e being bound for any of the exceptions... Michael Foord except TypeError or KeyError as msg: ! not-serious-ly y'rs, mwh ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
Skip try: Skip foo() Skip except TypeError with msg, KeyError with msg: Skip print msg fuzz Wasn't the proposal : fuzz try: fuzz something fuzz except NameError, OtherError as e: fuzz something... I'm not sure. I only saw SomeError as|with SomeValue. In your formulation the comma binds more tightly than the as keyword. In import statements it's the other way around. That seems like it might be a source of confusion. Skip ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
On 3/16/06, Alex Martelli [EMAIL PROTECTED] wrote: On Mar 16, 2006, at 7:30 PM, Brett Cannon wrote: ... I agree. as is taking on the use of assignment in statements that are not ``=`` and I say we just keep on with that. Plus Greg's above Hmmm, if we allowed '(expr as var)' for generic expr's we'd make a lot of people pining for 'assignment as an expression' very happy, wouldn't we...? Yes, but I don't want them to be happy. =) -Brett ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
On Fri, 17 Mar 2006, [EMAIL PROTECTED] wrote: [...] fuzz Wasn't the proposal : fuzz try: fuzz something fuzz except NameError, OtherError as e: fuzz something... I'm not sure. I only saw SomeError as|with SomeValue. Fuzzyman is right. In your formulation the comma binds more tightly than the as keyword. In import statements it's the other way around. That seems like it might be a source of confusion. Perhaps parentheses around the exception list should be mandatory for the 2-or-more exceptions case? except NameError as e: -- fine except (NameError) as e:-- fine except (NameError,) as e: -- fine except NameError, OtherError as e: -- SyntaxError except (NameError, OtherError) as e:-- fine John ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
Brett Cannon wrote: On 3/17/06, Georg Brandl [EMAIL PROTECTED] wrote: John J Lee wrote: In your formulation the comma binds more tightly than the as keyword. In import statements it's the other way around. That seems like it might be a source of confusion. Perhaps parentheses around the exception list should be mandatory for the 2-or-more exceptions case? except NameError as e: -- fine except (NameError) as e:-- fine except (NameError,) as e: -- fine except NameError, OtherError as e: -- SyntaxError except (NameError, OtherError) as e:-- fine I don't like that particularly, but I guess that for consistency's sake it would have to be done this way. I don't like it period. What consistency problem is there? This is Python 3 we are talking about, so if something makes good sense such as not having parentheses, I say leave them off. There are multiple places where parens could be required but are not, like multiple assignment. I only think of consistency with the usage of as in the import statement. I know how it works, but I predict people will come and write except NameError as e, OtherError as f: Georg ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
On 3/17/06, Georg Brandl [EMAIL PROTECTED] wrote: Brett Cannon wrote: On 3/17/06, Georg Brandl [EMAIL PROTECTED] wrote: John J Lee wrote: In your formulation the comma binds more tightly than the as keyword. In import statements it's the other way around. That seems like it might be a source of confusion. Perhaps parentheses around the exception list should be mandatory for the 2-or-more exceptions case? except NameError as e: -- fine except (NameError) as e:-- fine except (NameError,) as e: -- fine except NameError, OtherError as e: -- SyntaxError except (NameError, OtherError) as e:-- fine I don't like that particularly, but I guess that for consistency's sake it would have to be done this way. I don't like it period. What consistency problem is there? This is Python 3 we are talking about, so if something makes good sense such as not having parentheses, I say leave them off. There are multiple places where parens could be required but are not, like multiple assignment. I only think of consistency with the usage of as in the import statement. I know how it works, but I predict people will come and write except NameError as e, OtherError as f: Really? I don't. 'while' statement doesn't work that way either. I don't personally associate 'as' with any specific statement that uses it. Plus the above is bad since those should be separate 'except' clauses if people need to differentiate between what exceptions they caught. Otherwise it should be ambiguous and assigned to a single variable name. -Brett ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
Oleg Broytmann wrote: On Fri, Mar 17, 2006 at 07:44:51PM +, John J Lee wrote: Perhaps parentheses around the exception list should be mandatory for the 2-or-more exceptions case? except NameError as e: -- fine except (NameError) as e:-- fine except (NameError,) as e: -- fine except NameError, OtherError as e: -- SyntaxError except (NameError, OtherError) as e:-- fine If parens are mandatory what is the difference from the current syntax? Why do we need as here? Why not stay with except (NameError, OtherError), e: Currently the comma is used for two very different purposes within the same clause, so it's far too easy to make the mistake: except NameError, OtherError: and then have to deal with the fact that OtherError isn't caught (and given how often unit tests fail to cover all error cases, it wouldn't be unusual for this bug to escape a unit testing regime, too). If this code is made to do the right thing, then there needs to be some other syntax to indicate the name that should be used for the value of the caught exception. as is already used as an embedded naming syntax in two places: - import statements use it for locate an object or module using one name, but bind it to a different name in this module In this case, the binding is restricted to a single name and is applied individually to each element of a comma separated list: import foo as a, bar as b, baz as c - with statements use it for retrieve the context manager for this context and bind the result of the manager's __enter__ method to this name In this case, the binding may be either a single name or a tuple of names, and the expression itself is limited to a single term - parentheses are required around both comma separated lists and unpacking to separate names is optional: with (foo, bar, baz) as (a, b, c): pass with (foo, bar, baz) as x: pass The proposal to use it for except clauses encounters a subtle difference - in the except clause, even if multiple exception types are listed in the clause, there is still only a single exception value to be bound to the name. The list of exception names merely limits the possible types for that exception, rather than their names. So, as a somewhat novel approach, what about putting the as *before* the list of exceptions types? After all, the thing being bound is the exception caught, not the possible list of types: except NameError, OtherError: # Exception value not bound except as ex, NameError, OtherError: # Exception value bound to ex I don't actually have a problem with simply tacking the clause on the end (with or without mandatory parentheses) but figured I'd throw this idea out as an option. I'm not sure whether the parallel with print and print stream, is a positive or a negative, though. . . Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
Georg Brandl wrote: I predict people will come and write except NameError as e, OtherError as f: Then they'll learn very fast not to write that, because they'll get a SyntaxError. Greg ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
Greg Ewing wrote: For Py3k, any thoughts on changing the syntax of the except clause from except type, value: to except type as value: so that things like except TypeError, ValueError: will do what is expected? +1 here I actually had a go at figuring how to do this a long while back, but I have no idea what I ended up doing with the code (I think it died along with the old hard drive in my laptop). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
Greg Ewing wrote: For Py3k, any thoughts on changing the syntax of the except clause from except type, value: to except type as value: so that things like except TypeError, ValueError: will do what is expected? +1. Fits well with the current use of as. Georg ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
On 3/16/06, Georg Brandl [EMAIL PROTECTED] wrote: +1. Fits well with the current use of as. I like it, but wonder about the false parallels below. My initial reaction is it's not worth worrying about as it's easy to learn as part of the import or except statements, and should do the right thing. Nobody would expect the second import to rename both items to q, and the first except clause would be a SyntaxError. from foo import bar as b, quux as q except TypeError as te, IndexError as ie from foo import bar, quux as q except TypeError, IndexError as e Michael -- Michael Urman http://www.tortall.net/mu/blog ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
Greg Ewing a écrit : except type as value: what about except type with value: a program dies with an error message, not as an error message. ciao, BC ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
In article [EMAIL PROTECTED], Greg Ewing [EMAIL PROTECTED] wrote: For Py3k, any thoughts on changing the syntax of the except clause from except type, value: to except type as value: so that things like except TypeError, ValueError: will do what is expected? Brilliant. I may be showing my clumsiness, but I catch multiple exceptions so rarely that I often stumble over this. -- Russell ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
Baptiste Carvello wrote: what about except type with value: a program dies with an error message, not as an error message. No. The exception object you're catching *is* the value, not something which *has* a value. I maintain that as is the correct word to use here. Greg ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
Greg Ewing [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Baptiste Carvello wrote: what about except type with value: a program dies with an error message, not as an error message. No. The exception object you're catching *is* the value, not something which *has* a value. I maintain that as is the correct word to use here. Besides which, 'with' is a (new) main (compound statement) keyword while 'as' is always subordinate and denoting a name to be used in the sequel. And I also like using it to separate classes to be caught from name binding of instance. tjr ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
Greg except type as value: Baptiste except type with value: Can I catch multiple exceptions with a single value in this case? Today, I write: try: foo() except (TypeError, KeyError), msg: print msg Either of the above seem like they'd require me to repeat the value, e.g: try: foo() except TypeError with msg, KeyError with msg: print msg Not very Pythonic methinks. Skip ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
On 3/16/06, Greg Ewing [EMAIL PROTECTED] wrote: Baptiste Carvello wrote: what about except type with value: a program dies with an error message, not as an error message. No. The exception object you're catching *is* the value, not something which *has* a value. I maintain that as is the correct word to use here. I agree. as is taking on the use of assignment in statements that are not ``=`` and I say we just keep on with that. Plus Greg's above explanation also makes sense to me; you are binding the exception to a name and treating as if it was called value. -Brett ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
On Mar 16, 2006, at 7:30 PM, Brett Cannon wrote: ... I agree. as is taking on the use of assignment in statements that are not ``=`` and I say we just keep on with that. Plus Greg's above Hmmm, if we allowed '(expr as var)' for generic expr's we'd make a lot of people pining for 'assignment as an expression' very happy, wouldn't we...? Alex ___ 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
[Python-Dev] Py3k: Except clause syntax
For Py3k, any thoughts on changing the syntax of the except clause from except type, value: to except type as value: so that things like except TypeError, ValueError: will do what is expected? Greg ___ 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
Re: [Python-Dev] Py3k: Except clause syntax
On 3/15/06, Greg Ewing [EMAIL PROTECTED] wrote: For Py3k, any thoughts on changing the syntax of the except clause from except type, value: to except type as value: so that things like except TypeError, ValueError: will do what is expected? Not a bad idea. The trend seems to be that each use of 'as' is some kind of assignment to the name after 'as' but the relationship with the thing before 'as' is different in each case. -- --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
