I sense a religious fervor about this so go ahead and do whatever you
want.
Please register my -1 for the following reasons:
a.) It re-introduces representation error into a module that worked so
hard to overcome that very problem. The PEP explicitly promises that a
transformation from a literal
[Guido van Rossum]
> I know I should stay out of here,
Hey, it's still your language .
> but isn't Decimal() with a string literal as argument a rare
> case (except in examples)? It's like float() with a string
> argument -- while you *can* write float("1.01"), nobody does
> that. What people do
I know I should stay out of here, but isn't Decimal() with a string
literal as argument a rare case (except in examples)? It's like
float() with a string argument -- while you *can* write float("1.01"),
nobody does that. What people do all the time is parse a number out of
some larger context into
[Greg Ewing]
> I don't see it's because of that. Even if D(whatever)
> didn't ignore the context settings, you'd get the same
> oddity if the numbers came from somewhere else with a
> different precision.
Most users don't change context precision, and in that case there is
no operation defined in
Tim Peters wrote:
> [Raymond Hettinger]
>from decimal import getcontext, Decimal as D
>getcontext().prec = 3
>D('3.104') + D('2.104')
>>
>>Decimal("5.21")
>>
>D('3.104') + D('0.000') + D('2.104')
>>
>>Decimal("5.20")
>
> the results differ here because D(whatever)
> ignores contex
Sorry, I simply can't make more time for this. Shotgun mode:
[Raymond]
> I have no such thoughts but do strongly prefer the current
> design.
How can you strongly prefer it? You asked me whether I typed floats
with more than 28 significant digits. Not usually . Do you?
If you don't either, h
[Tim suggesting that I'm clueless and dazzled by sparkling lights]
> There seems to be an unspoken "wow that's cool!" kind of belief
> that because Python's Decimal representation is _potentially_
> unbounded, the constructor should build an object big enough to
> hold any argument exactly (up t
[Raymond Hettinger]
> For brevity, the above example used the context free
> constructor, but the point was to show the consequence
> of a precision change.
Yes, I understood your point. I was making a different point:
"changing precision" isn't needed _at all_ to get surprises from a
constructo
[Phillip J. Eby]
> Now you've shaken my faith in Uncle Timmy. :)
Now, now, a mere technical matter is no cause for soul-damning heresy!
> Seriously, he did *say*:
>
> """For example, it doesn't know the difference between an object
> that's in a trash cycle, and an object that's not in a trash
[Phillip J. Eby]
> ...
> However, Tim's new post brings up a different issue: if the collector can't
> tell the difference between a cycle participant and an object that's only
> reachable from a cycle, then the mere existence of a generator __del__ will
> prevent the cycle collection of the entire
At 07:18 PM 5/19/2005 +0100, Michael Hudson wrote:
>"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
>
> > However, Tim's new post brings up a different issue: if the collector
> can't
> > tell the difference between a cycle participant and an object that's only
> > reachable from a cycle,
>
>Uh, that
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> However, Tim's new post brings up a different issue: if the collector can't
> tell the difference between a cycle participant and an object that's only
> reachable from a cycle,
Uh, that's not what he meant:
/>> class C:
|.. def __del__(self):
|.
At 10:48 AM 5/19/2005 -0700, Guido van Rossum wrote:
>Hm. The way I see it, as soon as a generator raises an exception, its
>frame is part of a cycle: the frame's f_exc_traceback points to the
>traceback object, and the traceback object's tb_frame points back to
>the frame. So that's a cycle right
[Phillip J. Eby]
> >Throwing an exception also provides ample opportunity for creating
> >cycles, since the frame hold a reference to the most recent traceback.
> >Ironically, throwing an exception with a traceback into a generator is
> >likely to cause a cycle because the traceback likely referenc
[Guido]
> ...
> I think in the past I've unsuccessfully tried to argue that if a
> cycle contains exactly one object with a Python-invoking finalizer,
> that finalizer could be invoked before breaking the cycle. I still
> think that's a sensible proposal, and generators may be the use case
> to fin
Here's the word on GC vs. __del__, by the way.
-- Forwarded message --
From: Tim Peters <[EMAIL PROTECTED]>
Date: May 19, 2005 10:24 AM
Subject: Re: [Python-Dev] Combining the best of PEP 288 and PEP 325:
generator exceptions and cleanup
To: [EMAIL PROTECTED]
> Remind me. Why aga
At 10:09 AM 5/19/2005 -0700, Guido van Rossum wrote:
>[Phillip J. Eby]the only way a generator-iterator can become
> > part of a cycle is via an action taken outside the generator. (E.g.
> > passing it into itself via 'continue', creating a link from one of its
> > arguments to it, etc.) So, it'
> BTW I think that close() and __del__() should raise an exception when
> the throw(GeneratorExit) call doesn't end up either re-raising
> GeneratorExit or raising StopIteration. The framework for calling
> __del__() takes care of handling this exception (by printing and then
> ignoring it). Raymon
[Phillip J. Eby]the only way a generator-iterator can become
> part of a cycle is via an action taken outside the generator. (E.g.
> passing it into itself via 'continue', creating a link from one of its
> arguments to it, etc.) So, it's probably not a terrible limitation in
> practice.
It's en
[James Y Knigh]
> But you're missing the point -- there's a *reason* that __del__
> interferes with cyclic GC. It doesn't just do it for the heck of it!
> You can't simply have the C delete call into python code...the
> objects the generator has references to may be invalid objects
> already becaus
At 12:36 PM 5/19/2005 -0400, James Y Knight wrote:
>On May 19, 2005, at 8:43 AM, Phillip J. Eby wrote:
>>At 06:09 PM 5/19/2005 +1200, Greg Ewing wrote:
>>>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).
>>>
>>
On May 19, 2005, at 8:43 AM, Phillip J. Eby wrote:
> At 06:09 PM 5/19/2005 +1200, Greg Ewing wrote:
>> 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 ineligi
> Not sure what the "right" answer is, but I wanted to stick my oar in
to
> say that I think that Decimal has not been in the field long enough or
> widely-enough used that we should feel that the API has been set in
> stone. If there's agreement that a mistake was made, let's fix it!
There is no
On 5/18/05, Aahz <[EMAIL PROTECTED]> wrote:
> Not sure what the "right" answer is, but I wanted to stick my oar in to
> say that I think that Decimal has not been in the field long enough or
> widely-enough used that we should feel that the API has been set in
> stone. If there's agreement that a
On 5/18/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> >>> from decimal import getcontext
> >>> context = getcontext()
> >>> x = context.create_decimal('3.104')
> >>> y = context.create_decimal('2.104')
> >>> z = context.create_decimal('0.000')
> >>> context.prec = 3
> >>> x + y
> Decimal("5.
Here's the first draft of the python-dev summary for the first half of
May. Please send any corrections or suggestions to the summarizers (CC'ed).
==
Summary Announcements
==
--
PEP 340 Episode 2: Revenge of the
At 06:09 PM 5/19/2005 +1200, Greg Ewing wrote:
>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
>hav
At 04:44 PM 5/19/2005 +1200, Greg Ewing wrote:
>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 som
On 5/19/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> 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
>
On Monday 16 May 2005 22:41, Ka-Ping Yee wrote:
> http://www.python.org/peps/pep-0344.html
| 2. Whenever an exception is raised, if the exception instance does
| not already have a '__context__' attribute, the interpreter sets
| it equal to the thread's exception context.
On Thu, 19 May 2005, Nick Coghlan wrote:
> With PEP 344, this could simply be:
>
>try:
>parser.parseFile(file)
>exeption Exception, exception:
>raise type(exception)("Error at line %s in file %s" % (x,y))
Only if we also made all exceptions new-style classes.
That's just a
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?)
It turns out my submission email took the scenic route, and I wasn't using a
proper text ed
Michael Chermside wrote:
> If I write
>
> with foo:
>BLOCK
>
> where I should have written
>
> with locked(foo):
>BLOCK
>
> ...it silently "succeeds" by doing nothing. I CLEARLY intended to
> do the appropriate cleanup (or locking, or whatever), but it doesn't
> happen.
Nicolas Fleury wrote:
> I do a lot of exception re-raising at work; I use that
> technique to add content to exception messages while
> keeping the original stack. I even created a reraise
> function that I use that way:
>
> try:
> parser.parseFile(file)
> exeption Exception, exception:
>
34 matches
Mail list logo
