The PEP has been rejected.
-Brett
On 8/25/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/25/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> > I wish Fredrik would chime in. He would
> > have something pithy, angry, and incisive to say about this.
>
> Raymond, I'm sick of the abuse
On 8/25/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Guido> It's never too early to start deprecating a feature we know will
> Guido> disappear in 3.0.
>
> Though if it's a widely used feature the troops will be highly annoyed by
> all the deprecation warnings. (Or does deprecatio
Guido> It's never too early to start deprecating a feature we know will
Guido> disappear in 3.0.
Though if it's a widely used feature the troops will be highly annoyed by
all the deprecation warnings. (Or does deprecation not coincide with
emitting warnings?)
Skip
_
Raymond Hettinger wrote:
>>Deprecation means your code will still work I hope every book that
>>documents "except:" also adds "but don't use this except under very
>>special circumstances".
>>
>>I think you're overreacting (again), Raymond. 3.0 will be much more
>>successful if we can introduce man
Guido van Rossum wrote:
> On 8/25/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
>
>>I wish Fredrik would chime in. He would
>>have something pithy, angry, and incisive to say about this.
>
>
> Raymond, I'm sick of the abuse. Consider the PEP rejected.
>
Perhaps you should go for the £10
[PLEASE IGNORE PREVIOUS EMAIL... I HIT [Send] BY MISTAKE]
Guido:
> But how about the following compromise: make it a silent deprecation
> in 2.5, and a full deprecation in 2.6.
Reinhold Birkenfeld:
> That said, I think that unless it is a new feature (like with statements)
> transitions to Pytho
Guido:
> But how about the following compromise: make it a silent deprecation
> in 2.5, and a full deprecation in 2.6.
Reinhold Birkenfeld:
> That said, I think that unless it is a new feature (like with statements)
> transitions to Python 3.0 shouldn't be enforced in the 2.x series. With 3.0,
> e
On 8/25/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> I wish Fredrik would chime in. He would
> have something pithy, angry, and incisive to say about this.
Raymond, I'm sick of the abuse. Consider the PEP rejected.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
Raymond Hettinger wrote:
>... I propose that the transition plan be as simple as introducing
> BaseException. This allows people to write code that will work on both
> 2.x and 3.0. It doesn't break anything.
>
> The guidance for cross-version (2.5 to 3.0) code would be:
>
> * To catch all but
> > Also, as we learned with apply(), even if
> > ignored, the deprecation machinery has a tremendous runtime cost.
None
> > of this will make upgrading to Py2.5 an attractive option.
>
> Not in this case; bare except: can be flagged by the parser so the
> warning happens only once per compilatio
Raymond Hettinger wrote:
>> Deprecation means your code will still work I hope every book that
>> documents "except:" also adds "but don't use this except under very
>> special circumstances".
>>
>> I think you're overreacting (again), Raymond. 3.0 will be much more
>> successful if we can introdu
On 8/25/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>[...] AFAICT, there is no other way to broadly
> catch exceptions not derived from Exception.
But there is rarely a need to do so. I bet you that 99 out of 100 bare
excepts in the stdlib could be replaced by "except Exception" without
break
On Thu, Aug 25, 2005 at 11:58:48AM -0400, Raymond Hettinger wrote:
> Deprecation is only warranted if the interim substitute works --
> AFAICT, there is no other way to broadly catch exceptions not
> derived from Exception.
This seems to get to the heart of the problem. I'm no fan of bare
excepts
> Deprecation means your code will still work I hope every book that
> documents "except:" also adds "but don't use this except under very
> special circumstances".
>
> I think you're overreacting (again), Raymond. 3.0 will be much more
> successful if we can introduce many of its features into 2.
On 8/25/05, Sjoerd Mullender <[EMAIL PROTECTED]> wrote:
> There is an important point, though. Recently I read complaints about
> the lack of backward compatibility in Python on the fedora-list (mailing
> list for users of Fedora Core). Somebody asked what language he should
> learn and people an
On 8/25/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> It's only an overstatement if Guido didn't mean what he said. If bare
> except clauses are deprecated in 2.x, it WILL affect tons of existing
> code and invalidate a portion of almost all Python books.
Deprecation means your code will sti
Michael Chermside wrote:
> Raymond writes:
>
>>Efforts to improve Py3.0 have spilled
>>over into breaking Py2.x code with no compensating benefits. [...]
>>We don't have to wreck 2.x in order to make 3.0 better.
>
>
> I think you're overstating things a bit here.
There is an important point, th
> > Efforts to improve Py3.0 have spilled
> > over into breaking Py2.x code with no compensating benefits. [...]
> > We don't have to wreck 2.x in order to make 3.0 better.
>
> I think you're overstating things a bit here.
It's only an overstatement if Guido didn't mean what he said. If bare
exc
Raymond writes:
> Efforts to improve Py3.0 have spilled
> over into breaking Py2.x code with no compensating benefits. [...]
> We don't have to wreck 2.x in order to make 3.0 better.
I think you're overstating things a bit here.
> Remember, the ONLY benefit from the whole PEP is that in 3.0, it w
> > OK, I'm convinced. Let's drop bare except for Python 3.0, and
> > deprecate them until then, without changing the meaning.
> >
>
> Woohoo
That's no cause for celebration. Efforts to improve Py3.0 have spilled
over into breaking Py2.x code with no compensating benefits. Bare
except clauses a
Guido van Rossum <[EMAIL PROTECTED]> writes:
> On 8/24/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
>> I really hope string exceptions can be killed off before 3.0. They
>> should be fully deprecated in 2.5.
>
> But what about class exceptions that don't inherit from Exception?
> That will take
On 8/24/05, James Y Knight <[EMAIL PROTECTED]> wrote:
> On Aug 24, 2005, at 9:39 PM, Brett Cannon wrote:
> > On 8/24/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >> On 8/24/05, James Y Knight <[EMAIL PROTECTED]> wrote:
> >>> I think it must be the case that raising an object which does not
> >
On Aug 24, 2005, at 9:39 PM, Brett Cannon wrote:
> On 8/24/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> On 8/24/05, James Y Knight <[EMAIL PROTECTED]> wrote:
>>> I think it must be the case that raising an object which does not
>>> derive from an exception class must be deprecated as well in
On 8/24/05, Brett Cannon <[EMAIL PROTECTED]> wrote:
> Is there any desire for a __future__ statement that makes it a syntax
> error? How about making 'raise' statements only work with objects
> that inherit from BaseException?
I doubt it. Few people are going to put a __future__ statement in to
m
On 8/24/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/24/05, Michael Chermside <[EMAIL PROTECTED]> wrote:
> > Explicit is better than Implicit. I think that in newly written code
> > "except Exception:" is better (more explicit and easier to understand)
> > than "except:" Legacy code that
On 8/24/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/24/05, James Y Knight <[EMAIL PROTECTED]> wrote:
> > I think it must be the case that raising an object which does not
> > derive from an exception class must be deprecated as well in order
> > for "except:" to be deprecated. Otherwise,
On 8/24/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
> I really hope string exceptions can be killed off before 3.0. They
> should be fully deprecated in 2.5.
But what about class exceptions that don't inherit from Exception?
That will take a while before we can deprecate that.
Anyway, there ha
"Raymond Hettinger" <[EMAIL PROTECTED]> writes:
>> > Hmm, that may not be a killer. I wonder if it is possible to treat
>> > BaseException as a constant (like we do with None) and teach the
>> > compiler to interpret it as catching anything that gets raised so
> that
>> > "except BaseException" w
> > Hmm, that may not be a killer. I wonder if it is possible to treat
> > BaseException as a constant (like we do with None) and teach the
> > compiler to interpret it as catching anything that gets raised so
that
> > "except BaseException" will work like a bare except clause does now.
>
> Sorry
On Wed, 2005-08-24 at 15:15, Raymond Hettinger wrote:
> Hmm, that may not be a killer. I wonder if it is possible to treat
> BaseException as a constant (like we do with None) and teach the
> compiler to interpret it as catching anything that gets raised so that
> "except BaseException" will work
[Guido van Rossum]
> > OK, I'm convinced. Let's drop bare except for Python 3.0, and
> > deprecate them until then, without changing the meaning.
> >
> > The deprecation message (to be generated by the compiler!) should
> > steer people in the direction of specifying one particular exception
> > (e
On Wed, 2005-08-24 at 12:38, "Martin v. Löwis" wrote:
> I personally dislike recording the execution path in
> local variables. This is like setting a flag in a loop
> before the break, and testing the flag afterwards.
> You can do this, but the else: clause of the loop is
> just more readable.
A
On 8/24/05, James Y Knight <[EMAIL PROTECTED]> wrote:
> I think it must be the case that raising an object which does not
> derive from an exception class must be deprecated as well in order
> for "except:" to be deprecated. Otherwise, there is nothing you can
> change "except:" to in order not to
Niko Matsakis wrote:
>>
>> txn = new_transaction()
>> try:
>> txn.begin()
>> rtn = do_work()
>> finally:
>> if exception_occurred():
>> txn.abort()
>> else:
>> txn.commit()
>> return rtn
>>
>
> Couldn't you just do:
>
> txn = new_transaction ()
> try
Niko Matsakis wrote:
> Couldn't you just do:
>
> txn = new_transaction ()
> try:
> complete = 0
> txn.begin ()
> rtn = do_work ()
> complete = 1
> finally:
> if not complete: txn.abort ()
> else: txn.commit ()
>
> and then not need new builtins or anything fancy?
I
>
> txn = new_transaction()
> try:
> txn.begin()
> rtn = do_work()
> finally:
> if exception_occurred():
> txn.abort()
> else:
> txn.commit()
> return rtn
>
Couldn't you just do:
txn = new_transaction ()
try:
complete = 0
txn.begin ()
Barry Warsaw wrote:
> I agree about bare except, but there is a very valid use case for an
> except clause that catches every possible exception. We need to make
> sure we don't overlook this use case. As an example, say I'm building a
> transaction-aware system, I'm going to want to write code l
On Aug 24, 2005, at 11:10 AM, Guido van Rossum wrote:
> On 8/24/05, Michael Chermside <[EMAIL PROTECTED]> wrote:
>
>> Explicit is better than Implicit. I think that in newly written code
>> "except Exception:" is better (more explicit and easier to
>> understand)
>> than "except:" Legacy code t
On 8/24/05, Michael Chermside <[EMAIL PROTECTED]> wrote:
> Explicit is better than Implicit. I think that in newly written code
> "except Exception:" is better (more explicit and easier to understand)
> than "except:" Legacy code that uses "except:" can remain unchanged *IF*
> the meaning of "excep
On Wed, 2005-08-24 at 10:34, James Y Knight wrote:
> I would rather see "except:" be deprecated eventually, and force the
> user to say either except Exception, except BaseException, or even
> better, except ActualExceptionIWantToCatch.
I agree about bare except, but there is a very valid use
On Aug 23, 2005, at 10:41 PM, Raymond Hettinger wrote:
> [Guido van Rossum]
>
>> If we syntactically enforce that the bare except, if present, must be
>> last, would that remove your objection? I agree that a bare except in
>> the middle is an anomaly, but that doesn't mean we can't keep bare
>>
Raymond Hettinger writes:
> The latest version of PEP 348 still proposes that a bare except clause
> will default to Exception instead of BaseException. Initially, I had
> thought that might be a good idea but now think it is doomed and needs
> to be removed from the PEP.
Guido writes:
> If we sy
Raymond Hettinger wrote:
> The latest version of PEP 348 still proposes that a bare except clause
> will default to Exception instead of BaseException. Initially, I had
> thought that might be a good idea but now think it is doomed and needs
> to be removed from the PEP.
One thing I assumed was t
> As for the rest, I'm not as sure and it would be helpful to get
> thoughts
> from others on this one. My sense is that blocking the clause from
> appearing in the middle is treating the symptom and not the disease.
+1
It would be better to prohibit bare except entirely (well, presumably
at
[Guido van Rossum]
> If we syntactically enforce that the bare except, if present, must be
> last, would that remove your objection? I agree that a bare except in
> the middle is an anomaly, but that doesn't mean we can't keep bare
> except: as a shorthand for except Exception:.
Hmm. Prohibiting
On 8/23/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> The latest version of PEP 348 still proposes that a bare except clause
> will default to Exception instead of BaseException. Initially, I had
> thought that might be a good idea but now think it is doomed and needs
> to be removed from the
The latest version of PEP 348 still proposes that a bare except clause
will default to Exception instead of BaseException. Initially, I had
thought that might be a good idea but now think it is doomed and needs
to be removed from the PEP.
A bare except belongs at the end of a try suite, not in th
47 matches
Mail list logo
