What c.l.py's opinions about Soft Exception?

[Lie]

On Mar 9, 4:31 pm, Kay Schluehr <kay.schlu... at gmx.net> wrote:
> On 9 Mrz., 09:30, Lie <Lie.1... at gmail.com> wrote:
> > On Mar 9, 12:05 pm, Kay Schluehr <kay.schlu... at gmx.net> wrote:
>
> > > On 9 Mrz., 04:51, Lie <Lie.1... at gmail.com> wrote:
>
> > > > A more through implementation would start from the raiser inspecting
> > > > the execution stack and finding whether there are any try block above
> > > > it, if no try block exist it pass silently and if one exist it will
> > > > check whether it have a matching except clause. This also circumvents
> > > > a problem that simple implementation have, as described below.
>
> > > This will not be easy in particular in the presence of inheritance and
> > > dynamism. There is no way to statically decide whether an exception
> > > BException has the type AException and will be caught by the except
> > > clause in
>
> > > try:
> > >     BLOCK
> > > except AException, e:
> > >     print "SoftException %s caught"%e
> > > A feasible solution was to invert the try...except statement and
> > > creating a continuation.
>
> > > catch AException, a:
> > >    print "SoftException A: %s"%a
> > > catch BException , b:
> > >    print "SoftException B: %s"%b
> > > ...
> > > in:
> > >    BLOCK
>
> > > Here each SoftException is raised initially when a catch clause is
> > > entered and a continuation is created that returns to the catch block
> > > of the raised SoftException if required. When a SoftException is
> > > raised within BLOCK a lookup will be made and if a corresponding
> > > SoftException was found that was raised by a catch-clause the current
> > > control flow will be suspended and the continuation is called.
>
> > I'd rather want to avoid any syntax changes, as I wished that Soft
> > Exception can be added to the language silently[1] so that new
> > programmers doesn't _need_ to know about it (although knowing it could
> > change the way they write codes to be more structured and simple).
>
> I just tried to save your proposal from being unimplementable. Maybe
> you can comment on it?

Perhaps I'm not the appropriate person to talk about whether unchanged
syntax is feasible for such implementation since I basically have no
idea about how Python's internals works. It's only that I think if
current syntax could be used, we could just use it (except if there is
a strong reason why it shouldn't be done).

> I know of course that syntax is Pythons holy cow but I'm not Guidos
> mouthpiece and have a different perspective on some aspects of the
> system for obvious reasons [1].

I agree, everybody have different perspective. But that differences is
what makes languages evolves as it'd be continuously searching for the
most optimal perspective.