But I only want the latter in Py3k, and I don't mind using a different API there, even potentially a separate check after evaluating 'E' but before checking whether it matches.
I think it's fine not to catch this in 2.6; after all it's a bug anyway so we're not expecting many occurrences. I don't think the 3.0 mode in 2.6 needs to catch existing bugs; it only needs to catch code that *works* in 2.6 but won' in 3.0. On 2/12/07, Brett Cannon <[EMAIL PROTECTED]> wrote: > On 2/11/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > Brett Cannon schrieb: > > > Right, but I wanted to be able to raise a warning. If that warning is > > > supposed to be treated as an exception the caller needs to let that > > > propagate. RIght now PyErr_GivenExceptionMatches() can in no way let > > > the caller know that fact > > > > I'm unclear why you want to warn in PyErr_GivenExceptionMatches: > > shouldn't you rather warn when the exception is raised? > > > > Guido wants both so that you don't end up with useless values in the > 'except' clause. So yes, things are checked at the time of raising an > exception, but that does not prevent someone from putting something in > an 'except' clause that is useless. > > -Brett > _______________________________________________ > Python-3000 mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-3000 > Unsubscribe: > http://mail.python.org/mailman/options/python-3000/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
