Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

Guido van Rossum wrote: > - When a generator is GC'ed, its close() method is called (which is a > no-op if it is already closed). Does this mean that all generators will be ineligible for cyclic garbage collection (since they implicitly have something equivalent to a __del__ method)? Other than

Re: [Python-Dev] PEP 344: Exception Chaining and Embedded Tracebacks

Guido van Rossum wrote: > Here's another rule-of-thumb: when the VM and the user *share* the > attribute space of an object, the VM uses system attributes; the VM > uses plain attributes for objects that it owns completely (like code > objects, frames and so on, which rarely figure user code except

Re: [Python-Dev] PEP 343 - New kind of yield statement?

Michael Hudson wrote: > This is, to me, neat and clear. I don't find the idea that iterators > are tied to exactly 1 for loop an improvement (even though they > usually will be). To fix this in a fully backward-compatible way, we need some way of distinguishing generators that expect to be final

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generatorexceptions and cleanup

Phillip J. Eby wrote: > My use case for throw() calls for the latter option; i.e., the exception is > raised by the yield expression at the resumption point. Keep in mind that > if the exception passes out of the generator, the throw() call will show in > the traceback anyway. It's unlikely th

[Python-Dev] Adding content to exception messages

Sorry if this message is not a direct reply to Ka-Ping Yee message on PEP344, I'm in vacation in China and there's a thing I must say that could make sense in PEP344. I do a lot of exception re-raising at work; I use that technique to add content to exception messages while keeping the original s

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

[Guido van Rossum] > I believe that in the discussion about PEP 343 vs. Nick's PEP 3XX > (http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html, still > awaiting PEP moderator approval I believe?) ... Nick hasn't submitted it for a PEP number yet. -- David Goodger

Re: [Python-Dev] Simpler finalization semantics (was Re: PEP 343 - Abstract Block Redux)

Guido writes: [a rather silly objection to Phillip's proposal that 'with x:' is a no-op when x lacks __enter__ and __exit__] > I know this is not a very strong argument, but my gut tells me this > generalization of the with-statement is wrong, so I'll stick to it > regardless of the strength

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325:generator exceptions and cleanup

> > So at this point it seems your proposal is just nailing down specifics > for > > the open parts of PEP 325. > > Or PEP 288? That has throw() (albeit with a different signature). I > could do without the attributes though (PEP 342 provides a much better > solution IMO). > > If either of those

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

At 01:28 PM 5/18/2005 -0400, Raymond Hettinger wrote: > > Okay. Maybe we should just update PEP 325, then? > >-1. > >Keep this separate. Have you read PEP 325 lately? Mostly the change would consist of deleting rejected options or moving them to a rejected options section. The only other chan

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generatorexceptions and cleanup

At 01:24 PM 5/18/2005 -0400, Raymond Hettinger wrote: > > - g.throw(type, value, traceback) causes the specified exception to be > > thrown at the place where the generator g is currently suspended. > >Are the value and traceback arguments optional as they are with the >current raise statement? If

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generatorexceptions and cleanup

> [Raymond Hettinger] > > Are the value and traceback arguments optional as they are with the > > current raise statement? If they are optional, what would the default > > be? I think the preferred choice is to have the call to the throw > > method be the anchor point. That makes sense in a trac

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generatorexceptions and cleanup

[Raymond Hettinger] > Are the value and traceback arguments optional as they are with the > current raise statement? If they are optional, what would the default > be? I think the preferred choice is to have the call to the throw > method be the anchor point. That makes sense in a traceback so y

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

> Okay. Maybe we should just update PEP 325, then? -1. Keep this separate. Raymond ___ 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/ar

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325:generator exceptions and cleanup

> > Should this maybe just be added to PEP 342? To me, PEP 342 has always > > seemed incomplete without ways to throw() and close(), but that could > > easily be just me. In any case I'd expect the implementation of > > 'next(arg)' to have some overlap with the implementation of 'throw()'. > > M

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generatorexceptions and cleanup

> I'd like to propose to make that a separate PEP, which can combine > elements of PEP 288 and PEP 325. +1 Overall, the combined PEP proposal looks pretty good. > - g.throw(type, value, traceback) causes the specified exception to be > thrown at the place where the generator g is currently su

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

[Phillip J. Eby] > Okay. Maybe we should just update PEP 325, then? It has much of the stuff > that we'd want in the new PEP, such as the rationale. Your new proposal, > AFAICT, is just a simple extension of the PEP 325 protocol (i.e., adding > 'throw()'), along with some decisions to resolve it

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

At 09:55 AM 5/18/2005 -0700, Guido van Rossum wrote: >[Phillip J. Eby] > > And there was much rejoicing in the land of the co-routiney > people. :) +1000. > > > > Should this maybe just be added to PEP 342? To me, PEP 342 has always > > seemed incomplete without ways to throw() and close(), but

Re: [Python-Dev] PEP 343 - Abstract Block Redux

Greg Ewing <[EMAIL PROTECTED]> writes: > Guido van Rossum wrote: > >> PEP 340 is still my favorite, but it seems there's too much opposition >> to it, > > I'm not opposed to PEP 340 in principle, but the > ramifications seemed to be getting extraordinarily > complicated, and it seems to be hamstru

Re: [Python-Dev] Simpler finalization semantics (was Re: PEP 343 -Abstract Block Redux)

[I apologize in advance if this sounds a bit disjointed... I started to argue one thing, but by the end had convinced myself of the opposite, and I re-wrote the email to match my final conclusion.] Guido writes: > About deleting VAR I have mixed feelings. [...] > I think that, given that we let th

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

[Phillip J. Eby] > And there was much rejoicing in the land of the co-routiney people. :) > +1000. > > Should this maybe just be added to PEP 342? To me, PEP 342 has always > seemed incomplete without ways to throw() and close(), but that could > easily be just me. In any case I'd expect the

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

On Wednesday 18 May 2005 17:39, Guido van Rossum wrote: > I believe that in the discussion about PEP 343 vs. Nick's PEP 3XX > (http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html, still > awaiting PEP moderator approval I believe?) the main difference is > that Nick proposes a way to inject a

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

At 09:39 AM 5/18/2005 -0700, Guido van Rossum wrote: >- g.throw(type, value, traceback) causes the specified exception to be >thrown at the place where the generator g is currently suspended. If >the generator catches the exception and yields another value, that is >the return value of g.throw(). I

[Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

I believe that in the discussion about PEP 343 vs. Nick's PEP 3XX (http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html, still awaiting PEP moderator approval I believe?) the main difference is that Nick proposes a way to inject an exception into a generator; and I've said a few times that I l

Re: [Python-Dev] Example for PEP 343

Phillip writes: > >@do_template > >def with_extra_precision(places=2): > > "Performs nested computation with extra digits of precision." > > decimal.getcontext().prec += 2 > > yield None > > decimal.getcontext().prec -= 2 > > Won't this do the wrong thing if something within the blo

Re: [Python-Dev] PEP 344: Exception Chaining and Embedded Tracebacks

Here's another rule-of-thumb: when the VM and the user *share* the attribute space of an object, the VM uses system attributes; the VM uses plain attributes for objects that it owns completely (like code objects, frames and so on, which rarely figure user code except for the explicit purpose of int

Re: [Python-Dev] Decimal construction

On Wed, May 18, 2005, Tim Peters wrote: > > I think it shows more why it was a mistake for the decimal constructor > to extend the standard (the string->decimal operation in the standard > respects context settings; the results differ here because D(whatever) > ignores context settings; having a co

Re: [Python-Dev] Request for dev permissions

Robert> P.S. Do you have a valid email address, RB? I wasn't able to fix Robert> up your nospam address by hand. That's because it didn't need fixing... Note Reinhold's sig: Reinhold> -- Reinhold> Mail address is perfectly valid! Skip _

Re: [Python-Dev] Example for PEP 343

Guido van Rossum wrote: > Anyway, perhaps we should provide this most general template: > > @do_template > def with_decimal_context(): > oldctx = decimal.getcontext() > newctx = oldctx.copy() > decimal.setcontext(newctx) > yield newctx > decimal.setcontext(oldctx)