Guido van Rossum wrote:
> Somehow it seems that exceptions keep getting permission to violate
> the rules... (E.g. the insistence on a fixed base class is also
> considered unpythonic in other contexts.) Maybe it's because they're
> "exceptions" ? :-)
>
> Anyway, I believe there's a use case for r
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 l
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
Nick Coghlan wrote:
> Guido van Rossum wrote:
> Someone else wrote:
>
> > raise FooException().with_traceback()
>
> Works for me.
I don't like that somehow -- it looks too clever.
Also it violates the general principle of mutating
methods not returning things. I know Guido said
he's willing to
Brett Cannon schrieb:
>> 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
