Hi!
Don't now if always, or in the last few months where I've been
following the issues more closely, but I found that are appearing a
lot of small RFEs in the tracker.
These normally are small but not trivial things. In most cases when I
read them I think "Mmm, yes... it won't hurt to have it, b
The tests for float.__format__ are breaking on Windows, because of this
issue: http://bugs.python.org/issue1600. Basically, Windows is using 3
digits for exponents < 100, and Linux (and at least MacOS) are using 2.
The patch attached to the issue proposes changing all platforms to use
at least
Greg Ewing wrote:
> Martin v. Löwis wrote:
>> when some caller of PyEval_EvalFrameEx still carries
>> a pointer to some object that got deleted, and then still some code can
>> get hold of the then-deleted object.
>
> I seem to have missed the beginning of this discussion.
> I don't see what the p
On 2/18/08, Facundo Batista <[EMAIL PROTECTED]> wrote:
> Hi!
>
> Don't now if always, or in the last few months where I've been
> following the issues more closely, but I found that are appearing a
> lot of small RFEs in the tracker.
>
> These normally are small but not trivial things. In most case
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> The problem is calls to Py_DECREF(self->attr) where some of the code
> invoked by __del__ manages to find a way back around to reference
> self->attr and gets access to a half-deleted object.
Don't you mean "__del__ manages to find a way back around to s
Hello,
Neil Schemenauer wrote:
> Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > The problem is calls to Py_DECREF(self->attr) where some of the code
> > invoked by __del__ manages to find a way back around to reference
> > self->attr and gets access to a half-deleted object.
>
> Don't you mean "__del_
-On [20080218 13:38], Virgil Dupras ([EMAIL PROTECTED]) wrote:
>Personally, I think that a bug tracker is a good place to keep RFE,
>not a PEP. I think that the PEP would tend to be cluttered with RFE
>nobody cares about forever. So the clutter can never be cleaned unless
>someo
Jeroen Ruigrok van der Werven wrote:
> -On [20080218 13:38], Virgil Dupras ([EMAIL PROTECTED]) wrote:
> >Personally, I think that a bug tracker is a good place to keep RFE,
> >not a PEP. I think that the PEP would tend to be cluttered with RFE
> >nobody cares about foreve
On Feb 17, 2008 12:29 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Jeffrey Yasskin wrote:
> > On Feb 16, 2008 3:12 PM, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
> >> Should we however intensively search and correct all of them?
> >> Is there a clever way to prevent these problems global
On Feb 18, 2008 11:11 AM, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
> Jeroen Ruigrok van der Werven wrote:
> > -On [20080218 13:38], Virgil Dupras ([EMAIL PROTECTED]) wrote:
> > >Personally, I think that a bug tracker is a good place to keep RFE,
> > >
-On [20080218 21:41], Brett Cannon ([EMAIL PROTECTED]) wrote:
>My issue with keeping the RFEs in the tracker as they are is that it
>artificially inflates the open issue count. Python does not have over
>1,700 open bugs.
An issue does not necessarily mean the same as bug. :)
Is it a bu
On 2/18/08, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On Feb 18, 2008 11:11 AM, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
> > Jeroen Ruigrok van der Werven wrote:
> > > -On [20080218 13:38], Virgil Dupras ([EMAIL PROTECTED]) wrote:
> > > >P
Jeroen Ruigrok van der Werven wrote:
> -On [20080218 21:41], Brett Cannon ([EMAIL PROTECTED]) wrote:
>> My issue with keeping the RFEs in the tracker as they are is that it
>> artificially inflates the open issue count. Python does not have over
>> 1,700 open bugs.
&
> > >
> > > PEP: -1
> > > tracker: +1
> >
> > I agree. Then we can set some status/keyword when the subject of a RFE
> > is accepted by core developers, saying "if someone proposes a patch,
> > it has a chance to be reviewed and applied".
> > It may incite occasional contributors to work on some of
Virgil Dupras wrote:
> On 2/18/08, Brett Cannon <[EMAIL PROTECTED]> wrote:
[...]
>> So I have no issue with keeping the RFEs in the tracker, at some point
>> I do want to change how they are represnted so that they are a
>> separate things from issues representing bugs and patches.
>>
>> -Brett
>
There is a post on boost (http://boost.org) about floating point utilities
that are being considered for review. This seems to have a lot of overlap
with python needs. I haven't reviewed this myself, but boost code is meant
to be quite portable. Here is the link:
http://tinyurl.com/2gg4z3
Steve Holden schrieb:
> Jeroen Ruigrok van der Werven wrote:
>> -On [20080218 21:41], Brett Cannon ([EMAIL PROTECTED]) wrote:
>>> My issue with keeping the RFEs in the tracker as they are is that it
>>> artificially inflates the open issue count. Python does not ha
Virgil Dupras wrote:
> On 2/18/08, Steve Holden <[EMAIL PROTECTED]> wrote:
>> I'm not sure we should be throwing RFE's away with such casual abandon
>> just because nobody had time to pay them any attention in six months -
>> nor bugs neither, come to that.
>
> Well, we have to evaluate the chance
On 2/18/08, Steve Holden <[EMAIL PROTECTED]> wrote:
> I appreciate the desire to "keep the issue tracker clean", but I think
> human intelligence needs to be applied to the task, not just a
> date-based cutoff.
Personally, the bug count doesn't bother me. I was just responding to
Brett's concerns
On 2/18/08, Steve Holden <[EMAIL PROTECTED]> wrote:
> I'm not sure we should be throwing RFE's away with such casual abandon
> just because nobody had time to pay them any attention in six months -
> nor bugs neither, come to that.
Well, we have to evaluate the chances of our older tickets to come
> > Which is why I propose to have a mechanism to close bugs and RFE
> > nobody cares about. over *1000* out of those 1700 open issues are 6+
> > months old.
> >
> I'm not sure we should be throwing RFE's away with such casual abandon
> just because nobody had time to pay them any attention in six
On Mon, Feb 18, 2008 at 05:48:57PM +0100, Amaury Forgeot d'Arc wrote:
> For example, in exception.c, BaseException_init() starts with the instruction:
> Py_DECREF(self->args);
> this may call __del__ on self->args
Ah, I understand now. We are not talking about tp_dealloc methods
(the GC takes
[Steve Holden]
> I appreciate the desire to "keep the issue tracker clean", but I think
> human intelligence needs to be applied to the task, not just a
> date-based cutoff.
I concur. The older bug reports are ones that have survived
past human-based clean-up efforts. They were left open as
a
I don't know if you're done with this already, but there's a lot of
experience suggesting such sweeps are quite dangerous. In the past,
whenever a sweep across the entire stdlib was done, it's always caused
a few breakages, some of which didn't get caught until the next
release.
Things to worry ab
> This is still valid? Should we start moving RFEs to this PEP and
> closing their issues in the tracker?
As other have indicated - PEP 42 was a mistake (IMO).
> Or should we try to get more discussion regarding these RFEs? Maybe,
> for example, a weekly digest where the latests RFEs added are se
On Feb 18, 2008 4:52 PM, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> That sucks. Most Py_DECREF calls are probably okay but it's going
> to be hard to find the ones that are not. I can't think of anything
> we can do to make this trap harder to fall into. Even using
> Py_CLEAR as a blunt tool
>> Most Py_DECREF calls are probably okay but it's going to be hard
>> to find the ones that are not.
>
> I suppose Py_DECREF is not the only source of trouble. Many calls
> to the Python API can end up calling arbitrary user code (via
> __getattr__, __getitem__, etc.). Whenever an object does t
> A simple way to do this would be to push objects whose
> refcounts had reached 0 onto a list instead of finalizing them
> immediately, and have PyEval_EvalFrameEx periodically swap
> in a new to-delete list and delete the objects on the old one.
Some of the memory management threads discussed so
> That sucks. Most Py_DECREF calls are probably okay but it's going
> to be hard to find the ones that are not.
Methinks that
egrep 'DECREF\([a-zA-Z0-9_]->[a-zA-Z0-9_]+\)' */*.c
gives a good overview - you should never DECREF a variable on heap.
In the trunk, this command finds 36 candidates. N
> Well, we have to evaluate the chances of our older tickets to come to
> completion. I'm of the opinion that ticket getting older have very
> small chances of ever being completed. RFE for python 2.4 are likely
> to be irrelevant.
Do you have any facts to base this theory on?
Two years for a bug
I wrote:
> Most Py_DECREF calls are probably okay but it's going to be hard
> to find the ones that are not.
I suppose Py_DECREF is not the only source of trouble. Many calls
to the Python API can end up calling arbitrary user code (via
__getattr__, __getitem__, etc.). Whenever an object does th
> The tests for float.__format__ are breaking on Windows, because of this
> issue: http://bugs.python.org/issue1600. Basically, Windows is using 3
> digits for exponents < 100, and Linux (and at least MacOS) are using 2.
Yes, this is very annoying and I once lost of lot of time because of the
W
"Eric Smith" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| The tests for float.__format__ are breaking on Windows, because of this
| issue: http://bugs.python.org/issue1600. Basically, Windows is using 3
| digits for exponents < 100, and Linux (and at least MacOS) are using 2.
|
On 2/19/08, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Well, we have to evaluate the chances of our older tickets to come to
> > completion. I'm of the opinion that ticket getting older have very
> > small chances of ever being completed. RFE for python 2.4 are likely
> > to be irrelevant.
>
34 matches
Mail list logo
