[Guido]
>>> Can I go ahead and approve this now?
[Michael Hudson]
>> While I see the cost of this PEP being pretty small, I see the benefit
>> the same way too.
[Guido]
> Sure. Let me approve it and we'll see if someone cares enough to implement it.
No one will scream if you approve it, but when
> > Can I go ahead and approve this now
>
> While I see the cost of this PEP being pretty small, I see the benefit
> the same way too.
Sure. Let me approve it and we'll see if someone cares enough to implement it.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum <[EMAIL PROTECTED]> writes:
> [Steven Bethard]
>> I have a feeling that it might actually be easier to continue to
>> document try/except and try/finally separately and then just give the
>> semantics of try/except/finally in terms of the other semantics. Take
>> a look at the Ja
[Steven Bethard]
> I have a feeling that it might actually be easier to continue to
> document try/except and try/finally separately and then just give the
> semantics of try/except/finally in terms of the other semantics. Take
> a look at the Java Language Specification[1] (pages 399-401) if you
On 5/11/05, Russell E. Owen <[EMAIL PROTECTED]> wrote:
> I think this would be a useful enhancement. It simplifies the published
> documentation a bit (no need to document try/except as a separate entity
> from try/finally) and I have plenty of cases where I'd like to take
> advantage of it.
I hav
In article <[EMAIL PROTECTED]>,
Timothy Fitz <[EMAIL PROTECTED]> wrote:
> > No, as except clauses can only occur before the finally clause, and
> > execution
> > should not go backwards.
>
> This restriction feels a bit arbitrary. I can guarantee someone is
> going to flatten this:
>
> try:
>
[Timothy Fitz]
> A more flexible approach would be to allow finally at the beginning or
> ending of the try statement. A more flexible approach would be to
> allow both, or even finally clauses mixed in.
-1000.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
> No, as except clauses can only occur before the finally clause, and execution
> should not go backwards.
This restriction feels a bit arbitrary. I can guarantee someone is
going to flatten this:
try:
try:
A
finally:
B
except IOError:
C
A more flexible approach would
Guido van Rossum wrote:
> > (to save typing, you can use an empty string or even
> > put quotes around the exception name, but that may
> > make it harder to spot the change)
>
> Yeah, but that will stop working in Python 3.0.
well, I tend to remove my debugging hacks once I've fixed
the bug. I
Guido van Rossum wrote:
> try_stmt: 'try' ':' suite
> (
> except_clause ':' suite)+
> ['else' ':' suite] ['finally' ':' suite]
> |
> 'finally' ':' suite
> )
>
> There is no real complexity in this grammar, it's unam
[Guido van Rossum]
> I like the solution that puts a bare "raise" at the top of the except
> clause.
Yes. Clean and simple enough. Thanks all! :-)
--
François Pinard http://pinard.progiciels-bpi.ca
___
Python-Dev mailing list
Python-Dev@python.org
[Fredrik]
> the standard pydiom for this is to change
>
> try:
> blabla
> except IOError:
> blabla
>
> to
>
> try:
> blabla
> except "debug": # IOError:
> blabla
>
> (to save typing, you can use an empty string or even
> put quotes around the exce
[me]
> > I can't see how this would ever do something different than your version.
[Reinhold]
> Well, in the original the call to action1 was wrapped in an additional
> try-except
> block.
Ah. Francois was misquoting it.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
François Pinard wrote:
> > > f = None
> > > try:
> > > f = action1(...)
> > > ...
> > > finally:
> > > if f is not None:
> > > action2(f)
> > f = action1()
> > try:
> > ...
> > finally:
> > action2(f)
> > I can't see how this would ever do some
François Pinard wrote:
> It happens once in a while that I want to comment out the except clauses
> of a try statement, when I want the traceback of the inner raising, for
> debugging purposes. Syntax forces me to also comment the `try:' line,
> and indent out the lines following the `try:' line.
Guido van Rossum wrote:
> [François Pinard]
>> It happens once in a while that I want to comment out the except clauses
>> of a try statement, when I want the traceback of the inner raising, for
>> debugging purposes. Syntax forces me to also comment the `try:' line,
>> and indent out the lines fo
[Guido van Rossum]
> [François Pinard]
>
> > It happens once in a while that I want to comment out the except
> > clauses of a try statement, when I want the traceback of the inner
> > raising, for debugging purposes. Syntax forces me to also comment
> > the `try:' line, and indent out the lines
[François Pinard]
> It happens once in a while that I want to comment out the except clauses
> of a try statement, when I want the traceback of the inner raising, for
> debugging purposes. Syntax forces me to also comment the `try:' line,
> and indent out the lines following the `try:' line. And
[Guido van Rossum]
> [Nick Coghlan]
> > > What does a try statement with neither an except clause nor a
> > > finally clause mean?
> [Greg Ewing]
>
> > I guess it would mean the same as
> >if 1:
> > ...
> I strongly disagree with this. [...]
Allow me a quick comment on this issue.
I
[Nick Coghlan]
>
> > What does a try statement with neither an except clause nor a finally
> > clause mean?
[Greg Ewing]
> I guess it would mean the same as
>
>if 1:
> ...
>
> Not particularly useful, but maybe it's not worth complexifying
> the grammar just for the sake of disallowin
Nick Coghlan wrote:
> What does a try statement with neither an except clause nor a finally clause
> mean?
I guess it would mean the same as
if 1:
...
Not particularly useful, but maybe it's not worth complexifying
the grammar just for the sake of disallowing it.
Also, some people mig
Eric Nieuwland wrote:
> Wouldn't it be easier to change it to:
>
> try_stmt: ('try' ':' suite (except_clause ':' suite)*
> ['else' ':' suite] ['finally' ':' suite] )
> ?
What does a try statement with neither an except clause nor a finally clause
mean?
Cheers,
Nick.
Reinhold Birkenfeld wrote:
> Changes to the grammar
>
> The grammar for the try statement, which is currently
>
> try_stmt: ('try' ':' suite (except_clause ':' suite)+
>['else' ':' suite] | 'try' ':' suite 'finally' ':'
> suite)
>
> would have to become
>
>
Michael Hudson wrote:
> "Shane Holloway (IEEE)" <[EMAIL PROTECTED]> writes:
>
>
>>And per the PEP, I think the explaining that::
>>
>> try:
>> A
>> except:
>> B
>> else:
>> C
>> finally:
>> D
>>
>>is *exactly* equivalent to::
>>
>> try:
>>
"Shane Holloway (IEEE)" <[EMAIL PROTECTED]> writes:
> And per the PEP, I think the explaining that::
>
> try:
> A
> except:
> B
> else:
> C
> finally:
> D
>
> is *exactly* equivalent to::
>
> try:
> try:
> A
>
[Shane Holloway]
> And per the PEP, I think the explaining that::
>
> try:
> A
> except:
> B
> else:
> C
> finally:
> D
>
> is *exactly* equivalent to::
>
> try:
> try:
> A
> except:
> B
> else:
>
And per the PEP, I think the explaining that::
try:
A
except:
B
else:
C
finally:
D
is *exactly* equivalent to::
try:
try:
A
except:
B
else:
C
finally:
D
R
Tim Peters wrote:
> [Reinhold Birkenfeld]
>> ...
>> I think the behaviour of the "else" clause is much harder to guess,
>> mainly when used with the looping constructs.
>
> No, that's obvious .
OK, I'm persuaded. Well you wield the Force, master.
> What about `else` mixed with try/except/finally
Tim> What about `else` mixed with try/except/finally?
Tim> try:
Tim> A
Tim> except:
Tim> B
Tim> else:
Tim> C
Tim> finally:
Tim> D
Tim> If A executes without exception, does D execute before or after C?
According to Guido, execution is A, C
[Reinhold Birkenfeld]
> ...
> I think the behaviour of the "else" clause is much harder to guess,
> mainly when used with the looping constructs.
No, that's obvious .
What about `else` mixed with try/except/finally?
try:
A
except:
B
else:
C
finally:
D
If A executes without excep
Guido van Rossum wrote:
> Nice one. Should be a piece of cake to implement. Please talk to
> [EMAIL PROTECTED] about getting it checked into the PEP database.
>
> I'm +1 on accepting this now -- anybody against?
>
I'm +1. A couple of us discussed this at PyCon during the last day of the
sprints
Tim Peters wrote:
> [Guido]
>> I'm +1 on accepting this now -- anybody against?
>
> I'm curious to know if you (Guido) remember why you removed this
> feature in Python 0.9.6? From the HISTORY file:
>
> """
> New features in 0.9.6:
> - stricter try stmt syntax: cannot mix except and finally clau
[Tim]
> I'm curious to know if you (Guido) remember why you removed this
> feature in Python 0.9.6? From the HISTORY file:
>
> """
> New features in 0.9.6:
> - stricter try stmt syntax: cannot mix except and finally clauses on 1 try
> """
>
> IIRC (and I may well not), half of people guessed wro
On Wed, 2005-05-04 at 14:41, Tim Peters wrote:
> IIRC (and I may well not), half of people guessed wrong about whether
> an exception raised in an "except:" suite would or would not skip
> execution of the same-level "finally:" suite.
It would not, obviously .
> try:
> 1/0
> except DivisionB
Guido> Nice one. Should be a piece of cake to implement. Please talk to
Guido> [EMAIL PROTECTED] about getting it checked into the PEP database.
Guido> I'm +1 on accepting this now -- anybody against?
I'm not against it, but I thought there were ambiguity reasons that this
construct
[Guido]
> I'm +1 on accepting this now -- anybody against?
I'm curious to know if you (Guido) remember why you removed this
feature in Python 0.9.6? From the HISTORY file:
"""
New features in 0.9.6:
- stricter try stmt syntax: cannot mix except and finally clauses on 1 try
"""
IIRC (and I may w
[ Guido ]:
> Nice one. Should be a piece of cake to implement. Please talk to
> [EMAIL PROTECTED] about getting it checked into the PEP database.
>
> I'm +1 on accepting this now -- anybody against?
+1
Last week, while I was giving a Python course (in Rio de Janeiro-Brazil)
some students attempt
On Wed, 2005-05-04 at 13:09, Guido van Rossum wrote:
> Nice one. Should be a piece of cake to implement. Please talk to
> [EMAIL PROTECTED] about getting it checked into the PEP database.
+1!
-Barry
signature.asc
Description: This is a digitally signed message part
Nice one. Should be a piece of cake to implement. Please talk to
[EMAIL PROTECTED] about getting it checked into the PEP database.
I'm +1 on accepting this now -- anybody against?
On 5/4/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
> Hello,
>
> after proposing this here (albeit deep in the
Hello,
after proposing this here (albeit deep in the PEP 340 thread) and
getting a somewhat affirmatory response from Guido, I have written
something that could become a PEP if sufficiently hatched...
---
PEP: XXX
Title: Unifying try-except and try-finally
Version: $Revis
40 matches
Mail list logo
