Brett Cannon [EMAIL PROTECTED] writes:
On 8/10/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
Then I don't follow what you mean by moved under os.
In other words, to get the exception, do ``from os import
WindowsError``. Unfortunately we don't have a generic win module to
put it
On 8/12/05, Thomas Heller [EMAIL PROTECTED] wrote:
Brett Cannon [EMAIL PROTECTED] writes:
On 8/10/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
Then I don't follow what you mean by moved under os.
In other words, to get the exception, do ``from os import
WindowsError``.
On Aug 9, 2005, at 7:15 PM, Raymond Hettinger wrote:
The data gathered by Jack and Steven's research indicate that the
number
of cases where TerminatingException would be useful is ZERO. Try
not to
introduce a new builtin that no one will ever use. Try not to add
a new
word whose
On Aug 10, 2005, at 7:45 PM, Raymond Hettinger wrote:
Then I don't follow what you mean by moved under os.
In other words, to get the exception, do ``from os import
WindowsError``. Unfortunately we don't have a generic win module to
put it under. Maybe in the platform module instead?
On Aug 11, 2005, at 2:41 PM, Josiah Carlson wrote:
Remember, the Exception reorganization is for Python 3.0/3k/whatever,
not for 2.5 .
Huh, I could *swear* we were talking about fixing things for
2.5...but I see at least the current version of the PEP says it's
talking about 3.0. If that's
On 8/11/05, James Y Knight [EMAIL PROTECTED] wrote:
On Aug 11, 2005, at 2:41 PM, Josiah Carlson wrote:
Remember, the Exception reorganization is for Python 3.0/3k/whatever,
not for 2.5 .
Huh, I could *swear* we were talking about fixing things for
2.5...but I see at least the current
On 8/11/05, James Y Knight [EMAIL PROTECTED] wrote:
If that's true, this is hardly worth discussing as
3.0 is never going to happen anyways.
You are wrong. So wrong.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev
[James Y Knight]
Huh, I could *swear* we were talking about fixing things for
2.5...but I see at least the current version of the PEP says it's
talking about 3.0. If that's true, this is hardly worth discussing as
3.0 is never going to happen anyways.
And here I was hoping this was an
WindowsError
This should be kept. Unlike module specific exceptions, this
exception
occurs in multiple places and diverse applications. It is
appropriate
to list as a builtin.
Too O/S specific is not a reason for eliminating this. Looking at
the
codebase there
On 8/10/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
WindowsError
This should be kept. Unlike module specific exceptions, this
exception
occurs in multiple places and diverse applications. It is
appropriate
to list as a builtin.
Too O/S specific is not a
Then I don't follow what you mean by moved under os.
In other words, to get the exception, do ``from os import
WindowsError``. Unfortunately we don't have a generic win module to
put it under. Maybe in the platform module instead?
-1 on either. The WindowsError exception needs to in the
On 8/10/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
Then I don't follow what you mean by moved under os.
In other words, to get the exception, do ``from os import
WindowsError``. Unfortunately we don't have a generic win module to
put it under. Maybe in the platform module instead?
On Wed, Aug 10, 2005, Brett Cannon wrote:
On 8/10/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
If the name bugs you, I would support renaming it to PlatformError or
somesuch. That would make it free for use with Mac errors and Linux
errors. Also, it wouldn't tie a language feature to the
[Brett Cannon wrote]
Where is it used so much? In the stdlib, grepping for WindowsError
recursively in Lib in 2.4 turns up only one module raising it
(subprocess) and only two modules with a total of three places of
catching it (ntpath once, urllib twice). In Module, there are no
hits.
On 8/10/05, Aahz [EMAIL PROTECTED] wrote:
On Wed, Aug 10, 2005, Brett Cannon wrote:
On 8/10/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
If the name bugs you, I would support renaming it to PlatformError or
somesuch. That would make it free for use with Mac errors and Linux
errors.
[Brett]
I can compromise to this if others prefer this alternative. Anybody
else have an opinion?
We're not opinion shopping -- we're looking for analysis. Py3.0 is not
supposed to just a Python variant -- it is supposed to be better. It is
not about making compromises -- it is about only
There
is a reason you listed writing a PEP on your own on the School of
Hard Knocks list; it isn't easy. I am trying my best here.
Hang in there. Do what you can to make sure we get a result we can live
with.
-- R
___
Python-Dev mailing list
Raymond Hettinger wrote:
TerminatingException
The rationale for adding TerminatingException needs to be developed or
reconsidered. AFAICT, there hasn't been an exploration of existing code
bases to determine that there is going to be even minimal use of except
On 8/8/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
[Brett Cannon]
At this point the only
changes to the hierarchy are the addition of BaseException and
TerminatingException, and the change of inheritnace for
KeyboardInterrupt, SystemExit, and NotImplementedError.
[Brett]
The problem with existing code checking for this situation is that the
situation itself is not the same as it will be if bare 'except's
change::
try:
...
except:
...
except TerminatingException:
...
has never really been possible before, but will be if the PEP
version 1.7 scales the proposal back once more
(http://www.python.org/peps/pep-0348.html). At this point the only
changes to the hierarchy are the addition of BaseException and
TerminatingException, and the change of inheritnace for
KeyboardInterrupt, SystemExit, and NotImplementedError. At this
[Brett Cannon]
At this point the only
changes to the hierarchy are the addition of BaseException and
TerminatingException, and the change of inheritnace for
KeyboardInterrupt, SystemExit, and NotImplementedError.
TerminatingException
The rationale for adding
22 matches
Mail list logo
