At 08:13 PM 3/24/2006 -0800, Guido van Rossum wrote:
>I think that the code you added:
>
>+except:
>+if sys.exc_info()[1] is not value:
>+raise
>
>could use a comment explaining what's going on;
Done.
> the difference between
>returning None and r
On 3/24/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 04:34 PM 3/24/2006 -0800, Guido van Rossum wrote:
> >You could probably tell the difference by comparing the exception it
> >raises to the exception you pass it.
>
> That's what I changed @contextmanager to do, because it's the only place
>
At 04:34 PM 3/24/2006 -0800, Guido van Rossum wrote:
>You could probably tell the difference by comparing the exception it
>raises to the exception you pass it.
That's what I changed @contextmanager to do, because it's the only place
where you have a good reason to re-raise (i.e., the generator r
On 3/24/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 03:50 PM 3/24/2006 -0800, Guido van Rossum wrote:
> >I'm not against recommending in the PEP that __exit__ shouldn't
> >re-raise but instead should return False to signal a re-raise, and
> >fixing any existing code that re-raises in __exit_
At 03:50 PM 3/24/2006 -0800, Guido van Rossum wrote:
>I'm not against recommending in the PEP that __exit__ shouldn't
>re-raise but instead should return False to signal a re-raise, and
>fixing any existing code that re-raises in __exit__. But I'm still
>questioning your use case; why is it importa
On 3/24/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 03:27 PM 3/24/2006 -0800, Guido van Rossum wrote:
> >I guess I like the ambiguity -- to the outer __exit__, it shouldn't
> >make any difference whether the exception was re-raised by the inner
> >__exit__ or by the finally clause containing
At 03:27 PM 3/24/2006 -0800, Guido van Rossum wrote:
>I guess I like the ambiguity -- to the outer __exit__, it shouldn't
>make any difference whether the exception was re-raised by the inner
>__exit__ or by the finally clause containing it. After all, if there
>*wasn't* an outer __exit__, there wo
On 3/24/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 03:05 PM 3/24/2006 -0800, Guido van Rossum wrote:
> >Oops, that's definitely a bug. Please go ahead and fix in both places.
>
> Will do.
>
>
> >(I'm still trying to fathom the other PEP 343 issue you brought up.)
>
> Here's the paragraph I'
At 03:05 PM 3/24/2006 -0800, Guido van Rossum wrote:
>Oops, that's definitely a bug. Please go ahead and fix in both places.
Will do.
>(I'm still trying to fathom the other PEP 343 issue you brought up.)
Here's the paragraph I'm proposing to add to the PEP to explain that issue:
NOTE: to
Oops, that's definitely a bug. Please go ahead and fix in both places.
(I'm still trying to fathom the other PEP 343 issue you brought up.)
--Guido
On 3/24/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> It appears that the contextmanager implementation (both in the stdlib and
> as described in
It appears that the contextmanager implementation (both in the stdlib and
as described in the PEP) doesn't correctly handle the case where the
generator yields a new value in response to throw(). It responds by
suppressing the original exception, but IIRC earlier versions of the PEP
threw a Ru
11 matches
Mail list logo
