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:
> [ 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
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
[ 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
___
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
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
On 8/3/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> [Guido van Rossum]
> > > 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.
>
> [James Y Kn
> The problem with Raisable
> is that it doesn't contain the word exception; perhaps we can call it
> BaseException?
+1
> A refinement might be to introduce something called Error, which would
> change the last part of the avove hierarchy as follows:
. . .
> This has a nice symmetry between E
[Guido van Rossum]
> > 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.
[James Y Knight]
> I don't see how that can work. Any solution that is expected
On 8/3/05, James Y Knight <[EMAIL PROTECTED]> wrote:
> On Aug 3, 2005, at 3:00 PM, Guido van Rossum wrote:
> > [...brain hums...]
> >
> > 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 b
On Aug 3, 2005, at 3:00 PM, Guido van Rossum wrote:
> [...brain hums...]
>
> 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. A
On 8/3/05, Russell E. Owen <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Brett Cannon <[EMAIL PROTECTED]> wrote:
>
> > New Hierarchy
> > =
> >
> > Exception
[SNIP]
> > +-- StandardError
[SNIP]
> > +-- EnvironmentError
> > +-- OSError
> > +-- IOError
>
> > Because of EIBTI?
>
> Don't know the acronym (and neither does acronymfinder.com).
Sorry. Explicit is Better than Implicit.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://m
In article <[EMAIL PROTECTED]>,
Brett Cannon <[EMAIL PROTECTED]> wrote:
> New Hierarchy
> =
>
> Exception
> +-- CriticalException (new)
> +-- KeyboardInterrupt
> +-- MemoryError
> +-- SystemError
> +-- ControlFlowException (new)
> +-- StopIteration
> +-- Generator
On 8/3/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
> Guido van Rossum <[EMAIL PROTECTED]> writes:
>
> > So here's a radical proposal (hear the scratching of the finglernail
> > on the blackboard? :-).
> >
> > Start with Brett's latest proposal. Goal: keep bare "except:" but
> > change it to catc
Guido van Rossum <[EMAIL PROTECTED]> writes:
> So here's a radical proposal (hear the scratching of the finglernail
> on the blackboard? :-).
>
> Start with Brett's latest proposal. Goal: keep bare "except:" but
> change it to catch only the part of the hierarchy rooted at
> StandardError.
>
> - C
On 8/3/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/3/05, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > On 8/3/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > So here's a radical proposal (hear the scratching of the finglernail
> > > on the blackboard? :-).
> > >
> > > Start with Bret
On 8/3/05, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 8/3/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > So here's a radical proposal (hear the scratching of the finglernail
> > on the blackboard? :-).
> >
> > Start with Brett's latest proposal.
>
> Including renaming (I want to know if you
On 8/3/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> So here's a radical proposal (hear the scratching of the finglernail
> on the blackboard? :-).
>
> Start with Brett's latest proposal.
Including renaming (I want to know if you support the renamings at
all, if I should make them more of an
On 8/3/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 11:10 PM 8/3/2005 +1000, Nick Coghlan wrote:
> > New exceptions:
> > - Raisable (new base)
> > - ControlFlow (inherits from Raisable)
> > - CriticalError (inherits from Raisable)
> > - GeneratorExit (inherits from
On 8/3/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Phillip J. Eby wrote:
> > +1. The main things that need fixing, IMO, are the need for critical and
> > control flow exceptions to be distinguished from "normal" errors. The rest
> > is mostly too abstract for me to care about in 2.x.
>
> I gue
So here's a radical proposal (hear the scratching of the finglernail
on the blackboard? :-).
Start with Brett's latest proposal. Goal: keep bare "except:" but
change it to catch only the part of the hierarchy rooted at
StandardError.
- Call the root of the hierarchy Raisable.
- Rename CriticalExc
On 8/2/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> The Py3.0 PEPs are a bit disconcerting. Without 3.0 actively in
> development, it is difficult to get the participation, interest, and
> seriousness of thought that we apply to the current release. The PEPs
> may have the effect of prematu
Nick Coghlan wrote:
> Phillip J. Eby wrote:
>
>>+1. The main things that need fixing, IMO, are the need for critical and
>>control flow exceptions to be distinguished from "normal" errors. The rest
>>is mostly too abstract for me to care about in 2.x.
>
>
> I guess, before we figure out "whe
At 11:10 PM 8/3/2005 +1000, Nick Coghlan wrote:
> New exceptions:
> - Raisable (new base)
> - ControlFlow (inherits from Raisable)
> - CriticalError (inherits from Raisable)
> - GeneratorExit (inherits from ControlFlow)
> Added inheritance:
> - Exception from R
Phillip J. Eby wrote:
> +1. The main things that need fixing, IMO, are the need for critical and
> control flow exceptions to be distinguished from "normal" errors. The rest
> is mostly too abstract for me to care about in 2.x.
I guess, before we figure out "where would we like to go?", we rea
At 09:02 PM 8/2/2005 -0400, Raymond Hettinger wrote:
>The Py3.0 PEPs are a bit disconcerting. Without 3.0 actively in
>development, it is difficult to get the participation, interest, and
>seriousness of thought that we apply to the current release. The PEPs
>may have the effect of prematurely fi
The Py3.0 PEPs are a bit disconcerting. Without 3.0 actively in
development, it is difficult to get the participation, interest, and
seriousness of thought that we apply to the current release. The PEPs
may have the effect of prematurely finalizing discussions on something
that still has an ether
28 matches
Mail list logo
