On Mar 9, 4:31 pm, Kay Schluehr <[EMAIL PROTECTED]> wrote: > On 9 Mrz., 09:30, Lie <[EMAIL PROTECTED]> wrote: > > On Mar 9, 12:05 pm, Kay Schluehr <[EMAIL PROTECTED]> wrote: > > > > On 9 Mrz., 04:51, Lie <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
