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.
>
"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.
|
> 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
>> 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
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
> 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
> 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
> 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
> 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
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
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
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
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
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
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
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
>
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.
&
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
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
> > >
> > > 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
-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 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 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
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 [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
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_
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
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
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
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
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
34 matches
Mail list logo
