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
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
[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
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
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
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
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
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
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:
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
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
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
[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
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
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
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
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
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
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
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
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
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
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
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.
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
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?
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
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
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
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
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
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
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
33 matches
Mail list logo
