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
* Greg Ewing <[EMAIL PROTECTED]> [2006-03-21 13:20:53 +1200]:
> 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
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 func
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
[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 th
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
On Friday 2006-03-17 05:04, Alex Martelli wrote:
> Hmmm, if we allowed '( as )' 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
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
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 f
Greg> On the other hand, in
Greg>except E1, E2 as e:
Greg> the E1, E2 is just a tuple expression, so it's
Greg> exactly equivalent to
Greg>except (E1, E2) as e:
The comma and "as" have different precedence in your proposed except clause
than they currently do in the
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* b
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 importan
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/mail
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
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
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 s
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.
>> >
>> > Per
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 e
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:
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 excepti
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 as|with .
Fuzzyman is right.
> In your formulation the comma bi
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 '( as )' for
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 as|with .
Michael Hudson wrote:
[EMAIL PROTECTED] writes:
Greg> except as :
Baptiste> except with :
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
[EMAIL PROTECTED] writes:
> Greg> except as :
>
> Baptiste> except with :
>
> 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 t
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 '( as )' for generic expr's we'd make
a lot of people pining for 'assignmen
Greg Ewing wrote:
> Baptiste Carvello wrote:
>
>> what about
>>
>> except with :
>>
>> 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 w
On 3/16/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Baptiste Carvello wrote:
>
> > what about
> >
> > except with :
> >
> > 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 ma
Greg> except as :
Baptiste> except with :
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:
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Baptiste Carvello wrote:
>
>> what about
>>
>> except with :
>>
>> 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
Baptiste Carvello wrote:
> what about
>
> except with :
>
> 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
__
In article <[EMAIL PROTECTED]>,
Greg Ewing <[EMAIL PROTECTED]> wrote:
> For Py3k, any thoughts on changing the syntax of
> the except clause from
>
>except , :
>
> to
>
>except as :
>
> so that things like
>
>except TypeError, ValueError:
>
> will do what is expected?
Brillian
Greg Ewing a écrit :
>except as :
>
what about
except with :
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
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
th
Greg Ewing wrote:
> For Py3k, any thoughts on changing the syntax of
> the except clause from
>
>except , :
>
> to
>
>except as :
>
> so that things like
>
>except TypeError, ValueError:
>
> will do what is expected?
+1. Fits well with the current use of "as".
Georg
__
Greg Ewing wrote:
> For Py3k, any thoughts on changing the syntax of
> the except clause from
>
>except , :
>
> to
>
>except as :
>
> 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
On 3/15/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> For Py3k, any thoughts on changing the syntax of
> the except clause from
>
>except , :
>
> to
>
>except as :
>
> so that things like
>
>except TypeError, ValueError:
>
> will do what is expected?
Not a bad idea. The trend seems to b
For Py3k, any thoughts on changing the syntax of
the except clause from
except , :
to
except as :
so that things like
except TypeError, ValueError:
will do what is expected?
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://ma
38 matches
Mail list logo
