TRUNK IS UNFROZEN, available for 2.6 work if you are so inclined
The release candidate is done - we creep ever closer to 2.5 final. Hoooray! All future 2.5 releases (including 2.5 final!) will now be done from the new release25-maint trunk (svn+ssh://pythondev@svn.python.org/python/branches/release25-maint) - so any changes you want to see after 2.5c1 and before 2.5 final will need to be applied to that branch as well as to the trunk. From now until the final release, I think we should say no checkins to the release25-maint branch without either myself or Neal signing off on it - for safety's sake, I'd recommend you email either the list here, or if you have to send private email, send it to both of us. If this policy offends you, please reply and let me know what you'd prefer. Right now, I don't really care about the trunk - although if you break the buildbot, I'm sure Neal will be very cranky at you :-) Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
Is the following fix for #1541682 okay? Georg Index: Doc/api/intro.tex =================================================================== --- Doc/api/intro.tex (Revision 51336) +++ Doc/api/intro.tex (Arbeitskopie) @@ -276,8 +276,12 @@ if (n < 0) return -1; for (i = 0; i < n; i++) { - if (PyObject_SetItem(target, i, item) < 0) + PyObject *index = PyInt_FromLong(i); + if (!index) return -1; + if (PyObject_SetItem(target, index, item) < 0) + return -1; + Py_DECREF(index); } return 0; }
On Thu, Aug 17, 2006 at 04:40:45PM +0200, Georg Brandl wrote:
Is the following fix for #1541682 okay?
Index: Doc/api/intro.tex =================================================================== --- Doc/api/intro.tex (Revision 51336) +++ Doc/api/intro.tex (Arbeitskopie) @@ -276,8 +276,12 @@ if (n < 0) return -1; for (i = 0; i < n; i++) { - if (PyObject_SetItem(target, i, item) < 0) + PyObject *index = PyInt_FromLong(i); + if (!index) return -1; + if (PyObject_SetItem(target, index, item) < 0) + return -1; + Py_DECREF(index); } return 0; }
Looks good to me. While you are on that page do you want to change l = PyList_New(3); x = PyInt_FromLong(1L); PySequence_SetItem(l, 0, x); Py_DECREF(x); x = PyInt_FromLong(2L); PySequence_SetItem(l, 1, x); Py_DECREF(x); x = PyString_FromString("three"); PySequence_SetItem(l, 2, x); Py_DECREF(x); to l = PyList_New(3); x = PyInt_FromLong(1L); PyList_SetItem(l, 0, x); x = PyInt_FromLong(2L); PyList_SetItem(l, 1, x); x = PyString_FromString("three"); PyList_SetItem(l, 2, x); The example code causes segfaults and probably always has (at last to 2.2) -Jack
Jack Diederich wrote:
Looks good to me. While you are on that page do you want to change
l = PyList_New(3); x = PyInt_FromLong(1L); PySequence_SetItem(l, 0, x); Py_DECREF(x); x = PyInt_FromLong(2L); PySequence_SetItem(l, 1, x); Py_DECREF(x); x = PyString_FromString("three"); PySequence_SetItem(l, 2, x); Py_DECREF(x);
to
l = PyList_New(3); x = PyInt_FromLong(1L); PyList_SetItem(l, 0, x); x = PyInt_FromLong(2L); PyList_SetItem(l, 1, x); x = PyString_FromString("three"); PyList_SetItem(l, 2, x);
The example code causes segfaults and probably always has (at last to 2.2)
Interesting! From a naive POV, the docs' example is quite right. The segfault occurs because list_ass_item Py_DECREFs the old item (which segfaults because the old items are NULL in a newly created list). PyList_SetItem does a Py_XDECREF. The docs to PyList_New, however, do not explicitly say that the new list must only be filled using PyList_SetItem. So please, someone, decide what's broken here! Georg
Georg Brandl wrote:
Jack Diederich wrote:
Looks good to me. While you are on that page do you want to change
l = PyList_New(3); x = PyInt_FromLong(1L); PySequence_SetItem(l, 0, x); Py_DECREF(x); x = PyInt_FromLong(2L); PySequence_SetItem(l, 1, x); Py_DECREF(x); x = PyString_FromString("three"); PySequence_SetItem(l, 2, x); Py_DECREF(x);
to
l = PyList_New(3); x = PyInt_FromLong(1L); PyList_SetItem(l, 0, x); x = PyInt_FromLong(2L); PyList_SetItem(l, 1, x); x = PyString_FromString("three"); PyList_SetItem(l, 2, x);
The example code causes segfaults and probably always has (at last to 2.2)
Interesting! From a naive POV, the docs' example is quite right.
The segfault occurs because list_ass_item Py_DECREFs the old item (which segfaults because the old items are NULL in a newly created list). PyList_SetItem does a Py_XDECREF.
The docs to PyList_New, however, do not explicitly say that the new list must only be filled using PyList_SetItem.
So please, someone, decide what's broken here!
Okay, now that I stumbled over and read the c.l.py thread, I think that we should * remove the faulty example (the correct one is already in there) * add a note to PyList_New that the new list must be filled with items before handing it to Python code or using it with abstract APIs such as PySequence_SetItem. Georg
Georg Brandl wrote:
Okay, now that I stumbled over and read the c.l.py thread, I think that we should
* remove the faulty example (the correct one is already in there) * add a note to PyList_New that the new list must be filled with items before handing it to Python code or using it with abstract APIs such as PySequence_SetItem.
a blurb at the beginning of the abstract API section that mentions that the abstract API should only be used on fully initialized Python objects might also be a good idea. </F>
On Thu, Aug 17, 2006 at 09:07:53PM +0200, Georg Brandl wrote:
Jack Diederich wrote:
Looks good to me. While you are on that page do you want to change
l = PyList_New(3); x = PyInt_FromLong(1L); PySequence_SetItem(l, 0, x); Py_DECREF(x); x = PyInt_FromLong(2L); PySequence_SetItem(l, 1, x); Py_DECREF(x); x = PyString_FromString("three"); PySequence_SetItem(l, 2, x); Py_DECREF(x);
to
l = PyList_New(3); x = PyInt_FromLong(1L); PyList_SetItem(l, 0, x); x = PyInt_FromLong(2L); PyList_SetItem(l, 1, x); x = PyString_FromString("three"); PyList_SetItem(l, 2, x);
The example code causes segfaults and probably always has (at last to 2.2)
Interesting! From a naive POV, the docs' example is quite right.
The segfault occurs because list_ass_item Py_DECREFs the old item (which segfaults because the old items are NULL in a newly created list). PyList_SetItem does a Py_XDECREF.
The docs to PyList_New, however, do not explicitly say that the new list must only be filled using PyList_SetItem.
So please, someone, decide what's broken here!
The docs, this is from a thread yesterday and today on c.l.py http://groups.google.com/group/comp.lang.python/browse_frm/thread/158c8797ee... -Jack
Georg Brandl wrote:
Is the following fix for #1541682 okay?
Georg
Index: Doc/api/intro.tex =================================================================== --- Doc/api/intro.tex (Revision 51336) +++ Doc/api/intro.tex (Arbeitskopie) @@ -276,8 +276,12 @@ if (n < 0) return -1; for (i = 0; i < n; i++) { - if (PyObject_SetItem(target, i, item) < 0) + PyObject *index = PyInt_FromLong(i); + if (!index) return -1; + if (PyObject_SetItem(target, index, item) < 0) + return -1; + Py_DECREF(index); } return 0; }
1. Why not simply change the code to call PySequence_SetItem instead of creating a Python integer from the C long which PyObject_SetItem will simply have to convert back to a C long anyway? 2. This example code needs to change to use Py_ssize_t instead of int to hold i and n (the same goes for other examples on this page, actually...). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
Nick Coghlan wrote:
Georg Brandl wrote:
Is the following fix for #1541682 okay?
Georg
Index: Doc/api/intro.tex =================================================================== --- Doc/api/intro.tex (Revision 51336) +++ Doc/api/intro.tex (Arbeitskopie) @@ -276,8 +276,12 @@ if (n < 0) return -1; for (i = 0; i < n; i++) { - if (PyObject_SetItem(target, i, item) < 0) + PyObject *index = PyInt_FromLong(i); + if (!index) return -1; + if (PyObject_SetItem(target, index, item) < 0) + return -1; + Py_DECREF(index); } return 0; }
1. Why not simply change the code to call PySequence_SetItem instead of creating a Python integer from the C long which PyObject_SetItem will simply have to convert back to a C long anyway?
Because this example is after a paragraph that explicitly mentions PyObject_SetItem. It could, however be changed to mention PySequence_SetItem, I think... Georg
2. This example code needs to change to use Py_ssize_t instead of int to hold i and n (the same goes for other examples on this page, actually...).
Cheers, Nick.
Anthony Baxter schrieb:
Right now, I don't really care about the trunk - although if you break the buildbot [...]
Thanks for reminding me. I just added a buildbot builder for the 2.5 branch (actually, the builder was already there, but I connected it with the web server), so you can now see the status of the 2.5 branch at http://www.python.org/dev/buildbot/2.5/ Regards, Martin
Anthony Baxter wrote:
The release candidate is done - we creep ever closer to 2.5 final. Hoooray!
All future 2.5 releases (including 2.5 final!) will now be done from the new release25-maint trunk (svn+ssh://pythondev@svn.python.org/python/branches/release25-maint) - so any changes you want to see after 2.5c1 and before 2.5 final will need to be applied to that branch as well as to the trunk.
From now until the final release, I think we should say no checkins to the release25-maint branch without either myself or Neal signing off on it - for safety's sake, I'd recommend you email either the list here, or if you have to send private email, send it to both of us. If this policy offends you, please reply and let me know what you'd prefer.
I'd like to commit this. It fixes bug 1542051. Index: Objects/exceptions.c =================================================================== --- Objects/exceptions.c (Revision 51363) +++ Objects/exceptions.c (Arbeitskopie) @@ -81,6 +81,7 @@ static void BaseException_dealloc(PyBaseExceptionObject *self) { + _PyObject_GC_UNTRACK(self); BaseException_clear(self); self->ob_type->tp_free((PyObject *)self); } @@ -456,6 +457,7 @@ static void SystemExit_dealloc(PySystemExitObject *self) { + _PyObject_GC_UNTRACK(self); SystemExit_clear(self); self->ob_type->tp_free((PyObject *)self); } @@ -562,6 +564,7 @@ static void EnvironmentError_dealloc(PyEnvironmentErrorObject *self) { + _PyObject_GC_UNTRACK(self); EnvironmentError_clear(self); self->ob_type->tp_free((PyObject *)self); } @@ -760,6 +763,7 @@ static void WindowsError_dealloc(PyWindowsErrorObject *self) { + _PyObject_GC_UNTRACK(self); WindowsError_clear(self); self->ob_type->tp_free((PyObject *)self); } @@ -1035,6 +1039,7 @@ static void SyntaxError_dealloc(PySyntaxErrorObject *self) { + _PyObject_GC_UNTRACK(self); SyntaxError_clear(self); self->ob_type->tp_free((PyObject *)self); } @@ -1551,6 +1556,7 @@ static void UnicodeError_dealloc(PyUnicodeErrorObject *self) { + _PyObject_GC_UNTRACK(self); UnicodeError_clear(self); self->ob_type->tp_free((PyObject *)self); }
On 8/18/06, Georg Brandl <g.brandl@gmx.net> wrote:
I'd like to commit this. It fixes bug 1542051.
Index: Objects/exceptions.c
... Georg, Did you still want to fix this? I don't remember anything happening with it. I don't see where _PyObject_GC_TRACK is called, so I'm not sure why _PyObject_GC_UNTRACK is necessary. You should probably add the patch to the bug report and we can discuss there. n
participants (7)
-
"Martin v. Löwis" -
Anthony Baxter -
Fredrik Lundh -
Georg Brandl -
Jack Diederich -
Neal Norwitz -
Nick Coghlan