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 a while
Here's August Part One. As usual, if anyone can spare the time to proofread
this, that would be great! Please send any corrections or suggestions to
Steve (steven.bethard at gmail.com) and/or me, rather than cluttering the
list. Ta!
=
Announcements
=
I must have missed this one:
Style for raising exceptions
Guido explained that these days exceptions should always be raised as::
raise SomeException(some argument)
instead of::
raise SomeException, some argument
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 will
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 still
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
On 8/25/05, M.-A. Lemburg [EMAIL PROTECTED] wrote:
I must have missed this one:
Style for raising exceptions
Guido explained that these days exceptions should always be raised as::
raise SomeException(some argument)
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.x. Many
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
The following message is a courtesy copy of an article
that has been posted to comp.lang.python as well.
Neil Schemenauer [EMAIL PROTECTED] writes on Mon, 22 Aug 2005 15:31:42 -0600:
...
Some code may require that str() returns a str instance. In the
standard library, only one such
Hi Martin (and everyone else); thanks for your mail. The N*N/2
invocations would explain why we saw such a large number of invocations
--- thanks for figuring it out. W.r.t. how we're invoking our script:
But if you're using CGI, you're importing your source on every
invocation.
Well, no.
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
breaking
On Wed, Aug 24, 2005 at 09:11:18PM +0200, Dieter Maurer wrote:
Neil Schemenauer [EMAIL PROTECTED] writes on Mon, 22 Aug 2005 15:31:42
-0600:
The code was fixed by changing
the line header = str(header) to:
if isinstance(header, unicode):
header =
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 many of its
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/)
[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 Python
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 argument
At 02:10 PM 8/25/2005 -0500, Ian Bicking wrote:
I was trying to translate a pattern that uses closures in a language
like Scheme (where closed values can be written to) to generators using
PEP 342, but I'm not clear exactly how it works; the examples in the PEP
have different motivations. Since I
Phillip J. Eby wrote:
At 02:10 PM 8/25/2005 -0500, Ian Bicking wrote:
I was trying to translate a pattern that uses closures in a language
like Scheme (where closed values can be written to) to generators using
PEP 342, but I'm not clear exactly how it works; the examples in the PEP
have
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
MAL I must have missed this one:
That's because it was brief and to the point, so the discussion lasted for
maybe three messages. Also, someone told us you were on holiday so we
thought we could squeak it through without you noticing. Darn those
Aussies. Late on the pydev summary again!
On 8/25/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I do have a followup question on the style thing. (I'll leave others to
answer MAL's question about optimization.) If I want to raise an exception
without an argument, which of the following is the proper form?
raise ValueError
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 deprecation not
23 matches
Mail list logo
