On 3/24/06, Phillip J. Eby wrote:

Okay - so allow them without warning or error, even if somebody does 'gen.throw("abc")'?

Correct. There's no current code that does this, and I doubt that few people will write any, so I don't see the value of trying to trap or warn for this case.

I was proposing to only add support for this if a non-None traceback is supplied. I guess I'm confused as to how you could end up with sys.exc_info()[2] not containing a traceback object.

I'm not sure either -- but there's so much convoluted code that I can't prove to myself it can't happen either.

The idea here was that the only valid use case I can think of for throw()-ing a string exception is when using throw() to propagate a previously-raised exception.

Since throw() is a new feature, it seems reasonable to me to not provide string exception support -- *except* for backward compatibility needs, such as propagating a string exception that was already raised elsewhere.

Thus, it's not a case of removing support for string exceptions, but rather introducing a new feature that doesn't support creating new code that raises string exceptions.

But, string exceptions definitely should be supported for propagation, because you a coroutine could call some old code that uses string exceptions, so you need to be able to re-throw() them to outer coroutines.

And I see no reason to complicate the code with an additional check that doesn't serve a purpose. The purpose of reminding people not to write g.throw("abc") seems artificial to me. I'd rather see less code, meaning less maintenance, and no need to remove the check later (or when I merge your changes into the p3yk branch). -- --Guido van Rossum (home page: http://www.python.org/~guido/)