[Python-Dev] PEP 340 - possible new name for block-statement

[Phillip J. Eby]

At 04:02 PM 4/29/05 -0700, Guido van Rossum wrote:
>Actually, I think this is a nice way to have my cake and eat it too:
>on the one hand, there still isn't any user-defined syntax, because
>the keyword-less block syntax is still fixed by the compiler. On the
>other hand, people are free to *think* of it as introducing syntax if
>it helps them understand the code better. Just as you can think of
>each distinct @decorator as a separate piece of syntax that modifies a
>function/method definition. And just as you can think of a function
>call as a user-defined language extension.

And, amusingly enough, those folks who wanted a decorator suite can now 
have their wish, e.g.:

     decorate(classmethod):
         def something(cls, blah):
             ...

Given a suitable frame-sniffing implementation of 'decorate'.  :)

By the way, I notice PEP 340 has two outstanding items with my name on 
them; let me see if I can help eliminate one real quick.

Tracebacks: it occurs to me that I may have unintentionally given the 
impression that I need to pass in an arbitrary traceback, when in fact I 
only need to pass in the current sys.exc_info().  So, if the error call-in 
doesn't pass in anything but an error flag, and the template iterator is 
supposed to just read sys.exc_info(), maybe that would be less of an 
issue?  For one thing, it would make handling arbitrary errors in the 
template block cleaner, because the traceback for unhandled errors in 
something like this:

     synchronized(foo):
         raise Bar

would look something like this:

     File .... line ... of __main__:
         synchronized(foo):
     File .... line ... of synchronized:
         yield
     File .... line ... of __main__:
         raise Bar

Which, IMO, is the "correct" traceback for this circumstance, although 
since the first and last frame would actually be the same, you'd probably 
only get the lower two entries (the yield and the raise), which is OK too I 
think.

Anyway, I mainly just wanted to note that I'd be fine with having a way to 
say, "Hey, there's an error, handle it" that doesn't allow passing in the 
exception or traceback, but is just a flag that means "look at Python's 
error state" instead of passing a value back in.

I can do this because when I need to pass in a traceback, it's because I'm 
trying to pass a terminated coroutine's error into another coroutine.  So, 
the traceback I want to pass in is Python's existing "last error" state anyway.