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)
To
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!
wink
Skip
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 common
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
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 block alters
the
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
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(). If
[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
[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 the
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 hamstrung by
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 that
[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 its
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()'.
Maybe, but
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:
[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
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 they
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 change
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 PEP
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
[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 http://python.net/~goodger
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
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 the
22 matches
Mail list logo
