On 2004 Jun 24, at 17:15, Jeremy Hylton wrote:
On Mon, 2004-06-21 at 01:22, "Martin v. Löwis" wrote:
"If no exception is active in the current scope, an exception is raised indicating this error."
"This" error probably being "no active exception", not "exception must not be NoneType".
We can determine statically whether an exception would active in the current scope, right? If the raise does not occur within an except handler, then there is no active exception in the current scope. I think it should be a SyntaxError.
Isn't the "raise" allowed to occur in a function that may be _called from_ an except handler? E.g.:
def foo(): ... print "do something here" ... raise ... try: 1/0 ... except Exception: foo()
as one might obtain from refactoring otherwise duplicated "clean up a few things after an exception, then propagate the exception" code into a function foo. Of course, this could easily be coded otherwise (just a bit more verbosely: keep the raise out of foo, use "foo(); raise" wherever foo is now called), but before making a SyntaxError out of a construct that's long been quite correct and may well be present in good working code one would surely need at least one transition release where the construct produces a warning, right? Indeed. I looked for examples in the Python standard library and it wasn't hard to find some (there may be others, I only did a quick rough search) -- compiler/pycodegen.py method visitSlice of class CodeGenerator has a bare raise as the very last line of code (NOT statically inside an except handler); idlelib/rpc.py has a really interesting construct in method handle_error of class RPCServer: try: raise except SystemExit: raise except: erf = sys.__stderr__ (etc etc) also found elsewhere in idlelib, and another simpler bare raise is also in handle_error in class MyMixinServer in test_socketserver.py (indeed such handle_error methods might seem good candidates for cases of "bare raise not statically within an except handler"). It appears to me that finding examples of use of a construct inside such "hallowed" code as found in the standard library further militates in favour of having to be very cautious before making that construct into a SyntaxError. Alex