[Raymond]
> > The following example shows the kind of oddity that can arise when
> > working with quantities that have not been rounded to the current
> precision:
> >
> > >>> from decimal import getcontext, Decimal as D
> > >>> getcontext().prec = 3
> > >>> D('3.104') + D('2.104')
> > Decimal("5.2
Reinhold Birkenfeld wrote:
> would anybody mind if I was given permissions on the tracker
> and CVS, for fixing small
> things like bug #1202475. I feel that I can help you others
> out a bit with this and
> I promise I won't change the interpreter to accept braces...
I made a patch for that on
Hello,
would anybody mind if I was given permissions on the tracker and CVS, for
fixing small
things like bug #1202475. I feel that I can help you others out a bit with this
and
I promise I won't change the interpreter to accept braces...
Reinhold
--
Mail address is perfectly valid!
[Raymond Hettinger]
> ...
> One more change: The final "return +s" should be unindented. It should
> be at the same level as the "do with_extra_precision()". The purpose of
> the "+s" is to force the result to be rounded back to the *original*
> precision.
>
> This nuance is likely to be the ban
Patch / Bug Summary
___
Patches : 339 open ( +7) / 2838 closed ( +4) / 3177 total (+11)
Bugs: 938 open (+11) / 4962 closed ( +3) / 5900 total (+14)
RFE : 187 open ( +1) / 157 closed ( +0) / 344 total ( +1)
New / Reopened Patches
__
Restore G
> +def sin(x):
> +"Return the sine of x as measured in radians."
> +do with_extra_precision():
> +i, lasts, s, fact, num, sign = 1, 0, x, 1, x, 1
> +while s != lasts:
> +lasts = s
> +i += 2
> +
On May 17, 2005, at 11:39 PM, Guido van Rossum wrote:
> [Raymond Hettinger]
>
>> However, for a general purpose wrapper, it is preferable to make a
>> context copy and then restore the context after the enclosed is run.
>> That guards against the enclosed block making any unexpected context
>> ch
[Raymond Hettinger]
> The sin() example is correct. The precision is changed and restored in
> the current context.
I got that eventually. :-)
> However, for a general purpose wrapper, it is preferable to make a
> context copy and then restore the context after the enclosed is run.
> That guards
> I don't see a call to setcontext() in the sin() example in the library
> reference. Is that document wrong? I thought that simply modifying the
> parameters of the current context would be sufficient.
The sin() example is correct. The precision is changed and restored in
the current context.
H
On May 17, 2005, at 10:36 PM, Guido van Rossum wrote:
> On 5/17/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
>>> I think you're missing a decimal.setcontext(newcontext) before the
>>> yield..
>>>
>>
>> Right.
>>
>
> I don't see a call to setcontext() in the sin() example in the library
> re
On 5/17/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > I think you're missing a decimal.setcontext(newcontext) before the
> > yield..
>
> Right.
I don't see a call to setcontext() in the sin() example in the library
reference. Is that document wrong? I thought that simply modifying the
para
Nick Coghlan wrote:
> Paul Moore wrote:
>
>>On 5/17/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>>
>>>Previously Belaboured Point? (Just guessing from context here, but if I'm
>>>right,
>>>that's one acronym I'm going to have to remember. . .)
>>
>>Practicality Beats Purity, surely...?
>
>
> D'
> I think you're missing a decimal.setcontext(newcontext) before the
> yield..
Right.
___
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/arc
Bob Ippolito wrote:
>> One more thought: Rather than just saving the precision, it is
>> likely wiser, safer, and more general to just save and restore the
>> whole context and let the wrapped block only work with a copy.
>>
>> oldcontext = decimal.getcontext()
>> newcontext = oldcontext
On May 17, 2005, at 9:02 PM, Raymond Hettinger wrote:
>>> What's the advantage of using two calls to getcontext() vs. saving
>>>
> the
>
>>> context in a local variable?
>>>
>>
>> I also prefer saving the context in a local variable but that is just
>>
> a
>
>> micro-optimization. The presentati
At 12:48 PM 5/18/2005 +1200, Greg Ewing wrote:
>Nick Coghlan wrote:
>
> >the_stmt = EXPR1
> >stmt_enter = getattr(the_stmt, "__enter__", None)
> >stmt_exit = getattr(the_stmt, "__exit__", None)
> >
> >if stmt_enter is None:
> >VAR1 = the_stmt
> >else:
> >VAR1 = s
Guido van Rossum wrote:
> Unfortunately I can't quite decide whether either rule applies in the
> case of exceptions.
I think you'd at least be justified in using the "magic" rule,
since they're set by the exception machinery.
Greg
___
Python-Dev mail
> > What's the advantage of using two calls to getcontext() vs. saving
the
> > context in a local variable?
>
> I also prefer saving the context in a local variable but that is just
a
> micro-optimization. The presentation with multiple calls to
> getcontext() was kept just to match the style of
And we're back at PEP 310 and you can't really write opening() as a generator.
On 5/17/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
>
> >the_stmt = EXPR1
> >stmt_enter = getattr(the_stmt, "__enter__", None)
> >stmt_exit = getattr(the_stmt, "__exit__", None)
> >
> >
Nick Coghlan wrote:
>the_stmt = EXPR1
>stmt_enter = getattr(the_stmt, "__enter__", None)
>stmt_exit = getattr(the_stmt, "__exit__", None)
>
>if stmt_enter is None:
>VAR1 = the_stmt
>else:
>VAR1 = stmt_enter()
If we're doing this, it might be better if VAR were
> What's the advantage of using two calls to getcontext() vs. saving the
> context in a local variable?
I prefer saving the context in a local variable but that is just a
micro-optimization. The presentation with multiple calls to
getcontext() was kept just to match the style of the original -- t
What's the advantage of using two calls to getcontext() vs. saving the
context in a local variable?
On 5/17/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:python-dev-
> > [EMAIL PROTECTED] On Behalf Of Phillip J. Eby
> > Se
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:python-dev-
> [EMAIL PROTECTED] On Behalf Of Phillip J. Eby
> Sent: Tuesday, May 17, 2005 6:06 PM
> To: Michael Chermside; [EMAIL PROTECTED]
> Cc: python-dev@python.org
> Subject: Re: [Python-Dev] Example for PEP 343
>
> At 02:42 PM
At 02:42 PM 5/17/2005 -0700, Michael Chermside wrote:
># = SAMPLE #1: increasing precision during a sub-calculation =
>
>import decimal
>
>@do_template
>def with_extra_precision(places=2):
> "Performs nested computation with extra digits of precision."
> decimal.getcontext().prec +
In PEP 343 Guido writes:
>8. Another use for this feature is the Decimal context. It's left
> as an exercise for the reader. (Mail it to me if you'd like to
> see it here.)
Here are two such examples. Pick your favorite for the PEP.
PS: Writing this helped convince me that allow
[Guido van Rossum]
> > I'm in favor of the general idea, but would like to separate the error
> > injection and finalization API for generators into a separate PEP,
> > which would then compete with PEP 288 and PEP 325.
[Nick Coghlan]
> Without that it pretty much devolves into the current version
But that could easily be fixed by appending the context to the end of
the chain, right?
On 5/17/05, Eric Nieuwland <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Consider
> >
> > try:
> > BLOCK
> > except EXCEPTION, VAR:
> > HANDLER
> >
> > I'd like to see this tr
Guido van Rossum wrote:
> Consider
>
> try:
> BLOCK
> except EXCEPTION, VAR:
> HANDLER
>
> I'd like to see this translated into
>
> try:
> BLOCK
> except EXCEPTION, VAR:
> __context = VAR
> try:
> HANDLER
> except Exception
At 07:41 AM 5/17/2005 -0700, Guido van Rossum wrote:
>Consider
>
> try:
> BLOCK
> except EXCEPTION, VAR:
> HANDLER
>
>I'd like to see this translated into
>
> try:
> BLOCK
> except EXCEPTION, VAR:
> __context = VAR
> try:
> HANDLER
At 07:17 AM 5/17/2005 -0700, Guido van Rossum wrote:
>The compiler must generate both code paths but one is wasted.
Not if the default behavior is encapsulated in PyResource_Enter()
(returning the object if no __enter__) and PyResource_Exit() (a no-op if no
__exit__). You're going to have to ha
At 11:03 PM 5/17/2005 +1000, Nick Coghlan wrote:
>Do you mean translating this:
>
>with EXPR1 as VAR1:
>BLOCK1
>
>To something along the lines of:
>
>the_stmt = EXPR1
>stmt_enter = getattr(the_stmt, "__enter__", None)
>stmt_exit = getattr(the_stmt, "__exit__", None)
>
>i
I figured out the semantics that I'd like to see intuitively for
setting the context. I'm not saying this is all that reasonable, but
I'd like throw it out anyway to see what responses it gets.
Consider
try:
BLOCK
except EXCEPTION, VAR:
HANDLER
I'd like to see this transl
[Guido van Rossum]
> > My rule has more to do with who "owns" the namespace on the one hand,
> > and with "magic" behavior caused (or indicated) by the presence of the
> > attribute on the other. Class or instance is irrelevant; that most
> > magic attributes live on classes or modules is just beca
[Nick Coghlan (replying to Phillip)]
> Do you mean translating this:
>
>with EXPR1 as VAR1:
>BLOCK1
>
> To something along the lines of:
>
>the_stmt = EXPR1
>stmt_enter = getattr(the_stmt, "__enter__", None)
>stmt_exit = getattr(the_stmt, "__exit__", None)
>
>if stmt
On Mon, May 16, 2005, Guido van Rossum wrote:
>
> My rule has more to do with who "owns" the namespace on the one hand,
> and with "magic" behavior caused (or indicated) by the presence of the
> attribute on the other. Class or instance is irrelevant; that most
> magic attributes live on classes or
Nick Coghlan wrote:
> Wouldn't that mean we run the risk of suppressing a *real* SystemExit if it
> occurs while a generator is being finalised?
>
> Perhaps a new exception IteratorExit, which is a subclass of SystemExit. Then
> well-behaved code wouldn't trap it accidentally, and the finalisati
Paul Moore wrote:
> On 5/17/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>>Previously Belaboured Point? (Just guessing from context here, but if I'm
>>right,
>> that's one acronym I'm going to have to remember. . .)
>
> Practicality Beats Purity, surely...?
D'oh! *slaps forehead*
Cheers,
Nick.
Phillip J. Eby wrote:
> I'm suggesting that we simply take Nick's proposal to its logical
> conclusion, and allow any object to be usable under "with", since it
> does not create any problems to do so. (At least, none that I can
> see.) A redundant 'with' does no harm; in the worst case it's j
On 5/17/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > [Greg Ewing]
> >
> >>I still think it's conceptually cleaner if the object
> >>you use to access the resource is created by the
> >>__enter__ method rather than being something pre-
> >>existing, but I'm willing to co
The current threadmodule.c does not seem to correctly support multiple
(sub) interpreters.
This became apparent when using jep - (a Java/Python bridge) and also
seems to cause problems with mod_python.
The incompatibility began in Python version 2.3.5 and has been traced to changes
to the 2.4 thr
Guido van Rossum wrote:
> [Nick Coghlan]
>
>>That would be good, in my opinion. I updated PEP 3XX to use this idea:
>>http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
>>
>>With that update (to version 1.6), PEP 3XX is basically PEP 343, but injecting
>>exceptions that occur into the templ
Guido van Rossum wrote:
> [Greg Ewing]
>
>>I still think it's conceptually cleaner if the object
>>you use to access the resource is created by the
>>__enter__ method rather than being something pre-
>>existing, but I'm willing to concede that PBP here.
>
>
> PBP? Google finds "Python Browser Po
Phillip J. Eby wrote:
> At 08:21 PM 5/16/2005 -0400, Jack Diederich wrote:
>
>>I still haven't gotten used to Guido's heart-attack inducing early
>>enthusiasm for strange things followed later by a simple proclamation
>>I like. Some day I'll learn that the sound of fingernails on the
>>chalkboard
43 matches
Mail list logo
