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 Barwould look something like this:
File .... line ... of __main__:
synchronized(foo):
File .... line ... of synchronized:
yield
File .... line ... of __main__:
raise BarWhich, 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.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
