James Y Knight <[EMAIL PROTECTED]> wrote:
> > OK, I'm changing my mind again about the names again.
> >
> > Exception as the root and StandardError can stay; the only new
> > proposal would then be to make bare 'except:' call StandardError.
>
> I don't see how that can work. Any solution that is
Hello,
This patch is about to celebrate its second birthday :-)
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790710&group_id=5470
It seems from the comments that the feature is nice but the
implementation was not OK.
I redid the implem according to the comments.
What should I
"Grégoire Dooms" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>This patch is about to celebrate its second birthday :-)
>What should I do to get it reviewed further ?
The guaranteed-by-a-couple-of-developers way is to review 5 other patches,
post a summary here, and name this as
One more thing. Is renaming NameError to NamespaceError really worth
it? I'd say that NameError is just as clear.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
[ Guido]
> One more thing. Is renaming NameError to NamespaceError really worth
> it? I'd say that NameError is just as clear.
+1 on NameError -- it's clear, easy to type, isn't a gratuitous change,
and doesn't make you think twice about NamespaceError vs NameSpaceError.
Raymond
___
Also strong -1 on renaming RuntimeWarning to SemanticsWarning.
Besides being another unnecessary change (trying to solve a non-existent
problem), this isn't an improvement. The phrase RuntimeWarning is
sufficiently generic to allow it to be used for a number of purposes.
In costrast, SemanticsWar
The PEP moves StopIteration out from under Exception so that it cannot
be caught by a bare except or an explicit "except Exception".
IMO, this is a mistake. In either form, a programmer is stating that
they want to catch and handle just about anything. There is a
reasonable argument that SystemE
On 8/5/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> The PEP moves StopIteration out from under Exception so that it cannot
> be caught by a bare except or an explicit "except Exception".
>
> IMO, this is a mistake. In either form, a programmer is stating that
> they want to catch and handle
On 8/4/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote (in the PEP):
> > KeyboardInterrupt inheriting from ControlFlowException
> >
> > KeyboardInterrupt has been a contentious point within this hierarchy. Some
> > view the exception as more control flow being caused by the user. B
At 02:46 PM 8/5/2005 -0400, Raymond Hettinger wrote:
>The PEP moves StopIteration out from under Exception so that it cannot
>be caught by a bare except or an explicit "except Exception".
>
>IMO, this is a mistake. In either form, a programmer is stating that
>they want to catch and handle just ab
> > When a user creates their own exception for exiting multiple levels
of
> > loops or frames, should they inherit from ControlFlowException on
the
> > theory that it no different in intent from StopIteration or should
they
> > inherit from UserError on the theory that it is a custom exception?
>
On Aug 5, 2005, at 2:46 PM, Raymond Hettinger wrote:
> The PEP moves StopIteration out from under Exception so that it cannot
> be caught by a bare except or an explicit "except Exception".
>
> IMO, this is a mistake. In either form, a programmer is stating that
> they want to catch and handle j
[Raymond Hettinger wrote]
> >The PEP moves StopIteration out from under Exception so that it
cannot
> >be caught by a bare except or an explicit "except Exception".
> >
> >IMO, this is a mistake. In either form, a programmer is stating that
> >they want to catch and handle just about anything. Th
On 8/4/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Since I forgot to mention it in the last couple of messages - this version
> looks very good. The transition strategy section makes it a lot more
> meaningful.
>
Great to hear!
> Brett Cannon wrote (in the PEP):
> > Renamed Exceptions
> >
> >
On 8/4/05, James Y Knight <[EMAIL PROTECTED]> wrote:
> >+-- NamespaceError (rename of NameError)
> >+-- UnboundFreeError (new)
> >+-- UnboundGlobalError (new)
> >+-- UnboundLocalError
> >
>
> What are these new exceptions for? Under what circumstances ar
On 8/4/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> In general the PEP looks really good now!
>
Glad you like it.
> On 8/4/05, Willem Broekema <[EMAIL PROTECTED]> wrote:
> > On 8/4/05, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > > OK, once the cron job comes around and is run,
> > > http://
Raymond Hettinger wrote:
> 2. There is a lesson to be taken from a story in the ACM risks forum
> where a massive phone outage was traced to a single line of C code that
> ran a "break" to get out of a nested if-statement. The interesting part
> is that this was known to be mission critical code
On 8/5/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> While I agree with most of your -1's on gratuitous changes, this particular
> problem isn't gratuitous. A StopIteration that reaches a regular exception
> handler is a programming error; allowing StopIteration and other
> control-flow exceptio
On 8/4/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> This does contradict my earlier claim that Python itself doesn't use
> RuntimeError; I think I'd be happier if it remained RuntimeError. (I
> think there are a few more uses of it inside Python itself; I don't
> think it's worth inventing ne
On 8/5/05, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 8/4/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> > This does contradict my earlier claim that Python itself doesn't use
> > RuntimeError; I think I'd be happier if it remained RuntimeError. (I
> > think there are a few more uses of it
On 8/5/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [ Guido]
> > One more thing. Is renaming NameError to NamespaceError really worth
> > it? I'd say that NameError is just as clear.
>
> +1 on NameError -- it's clear, easy to type, isn't a gratuitous change,
> and doesn't make you think twic
Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 8/4/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> I just realized that keeping RuntimeError still does not resolve the
> issue that the name kind of sucks for realizing intrinsically that it
> is for quick-and-dirty exceptions (or am I the only on
On 8/5/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Also strong -1 on renaming RuntimeWarning to SemanticsWarning.
>
> Besides being another unnecessary change (trying to solve a non-existent
> problem), this isn't an improvement. The phrase RuntimeWarning is
> sufficiently generic to allow
On 8/5/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > > When a user creates their own exception for exiting multiple levels
> of
> > > loops or frames, should they inherit from ControlFlowException on
> the
> > > theory that it no different in intent from StopIteration or should
> they
> > >
> "Grégoire Dooms" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> >This patch is about to celebrate its second birthday :-)
> >What should I do to get it reviewed further ?
> The guaranteed-by-a-couple-of-developers way is to review 5 other patches,
> post a summary here, and n
On 8/5/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
[SNIP]
> Those legitimate uses often need to make a special case of
> Keyboardinterrupt and SystemExit -- KeyboardInterrupt because it's not
> a bug in the code but a request from the user who is *running* the app
> (and the appropriate default
On 8/5/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/5/05, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > On 8/4/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >
> > > This does contradict my earlier claim that Python itself doesn't use
> > > RuntimeError; I think I'd be happier if it rema
On 8/5/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > On 8/4/05, James Y Knight <[EMAIL PROTECTED]> wrote:
> > > >+-- NamespaceError (rename of NameError)
> > > >+-- UnboundFreeError (new)
> > > >+-- UnboundGlobalError (new)
> > > >+-- UnboundLocalE
> > > > >+-- NamespaceError (rename of NameError)
> > > > >+-- UnboundFreeError (new)
> > > > >+-- UnboundGlobalError (new)
> > > > >+-- UnboundLocalError
> > > > >
> > > >
> > > > What are these new exceptions for? Under what circumstances are
they
> > >
29 matches
Mail list logo
