From noreply@sourceforge.net Sun Oct 1 00:59:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 30 Sep 2000 16:59:37 -0700 Subject: [Patches] [Patch #101714] Missing `s' in format string Message-ID: <200009302359.QAA02999@delerium.i.sourceforge.net> Patch #101714 has been updated. Project: Category: library Status: Closed Summary: Missing `s' in format string Follow-Ups: Date: 2000-Sep-30 16:59 By: fdrake Comment: Checked in as Lib/mailbox.py revision 1.25. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101714&group_id=5470 From noreply@sourceforge.net Sun Oct 1 01:01:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 30 Sep 2000 17:01:44 -0700 Subject: [Patches] [Patch #101713] Free extension DLLs' handles during the Py_Finalize() Message-ID: <200010010001.RAA03038@delerium.i.sourceforge.net> Patch #101713 has been updated. Project: Category: Windows Status: Open Summary: Free extension DLLs' handles during the Py_Finalize() Follow-Ups: Date: 2000-Sep-29 12:09 By: Markovitch Comment: This patch is intended to fix the following problem: Python on Windows never frees DLLs loaded as extension. Whenever it's not a big problem when the interpreter is being used in a standart way, it becomes THE problem (or even a disaster) when the interpreter DLL is dynamically initialized/finalized from one process many times during single run. Moreover, even in case of single initialization there is a trap - DLLs loaded by mistake are unloaded only then a process finishes (e.g. suppose there is a foo.dll in the current directory and foo.dll is NOT a Python extension; "import foo" ends up with error, but foo.dll will be anging in process' address space!) This patch 1) frees a DLL handle in case of it has no proper initialization funcion 2) registers in an internal array all handles of successfully loaded dynamic extensions 2) frees all registered handles during Py_Finalize() Yakov Markovitch, markovitch@iso.ru ------------------------------------------------------- Date: 2000-Sep-30 17:01 By: fdrake Comment: Assigned to one of our Windows guys for review. ------------------------------------------------------- Date: 2000-Sep-30 17:01 By: fdrake Comment: Assigned to one of our Windows guys for review. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101713&group_id=5470 From noreply@sourceforge.net Sun Oct 1 01:01:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 30 Sep 2000 17:01:44 -0700 Subject: [Patches] [Patch #101713] Free extension DLLs' handles during the Py_Finalize() Message-ID: <200010010001.RAA03039@delerium.i.sourceforge.net> Patch #101713 has been updated. Project: Category: Windows Status: Open Summary: Free extension DLLs' handles during the Py_Finalize() Follow-Ups: Date: 2000-Sep-29 12:09 By: Markovitch Comment: This patch is intended to fix the following problem: Python on Windows never frees DLLs loaded as extension. Whenever it's not a big problem when the interpreter is being used in a standart way, it becomes THE problem (or even a disaster) when the interpreter DLL is dynamically initialized/finalized from one process many times during single run. Moreover, even in case of single initialization there is a trap - DLLs loaded by mistake are unloaded only then a process finishes (e.g. suppose there is a foo.dll in the current directory and foo.dll is NOT a Python extension; "import foo" ends up with error, but foo.dll will be anging in process' address space!) This patch 1) frees a DLL handle in case of it has no proper initialization funcion 2) registers in an internal array all handles of successfully loaded dynamic extensions 2) frees all registered handles during Py_Finalize() Yakov Markovitch, markovitch@iso.ru ------------------------------------------------------- Date: 2000-Sep-30 17:01 By: fdrake Comment: Assigned to one of our Windows guys for review. ------------------------------------------------------- Date: 2000-Sep-30 17:01 By: fdrake Comment: Assigned to one of our Windows guys for review. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101713&group_id=5470 From noreply@sourceforge.net Sun Oct 1 01:06:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 30 Sep 2000 17:06:03 -0700 Subject: [Patches] [Patch #101724] Fix for 115714: Don't rename Tkinter to Tk Message-ID: <200010010006.RAA03229@delerium.i.sourceforge.net> Patch #101724 has been updated. Project: Category: Tkinter Status: Accepted Summary: Fix for 115714: Don't rename Tkinter to Tk Follow-Ups: Date: 2000-Sep-30 17:06 By: fdrake Comment: Don't add the comment about not re-exporting the "Tk" name -- it doesn't make sense except as a historical comment; that should be in the checkin comment, not the source file. Please make Error a subclass of Exception; tracebacks will be slightly easier to read since the exception itself will name the module that raised it. Please make these changes and check it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101724&group_id=5470 From noreply@sourceforge.net Sun Oct 1 01:10:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 30 Sep 2000 17:10:01 -0700 Subject: [Patches] [Patch #101721] Fix for 115530/1: add closed attribute to cStringIO objects Message-ID: <200010010010.RAA03382@delerium.i.sourceforge.net> Patch #101721 has been updated. Project: Category: None Status: Open Summary: Fix for 115530/1: add closed attribute to cStringIO objects Follow-Ups: Date: 2000-Sep-30 09:25 By: loewis Comment: I have updated the patch to also fix 115530. The only remaining difference to StringIO is that cStringIO.readline does not support a maxsize argument. To add this parameter, the C API of cStringIO must be changed, and in turn cPickle. Is such a correction desirable? ------------------------------------------------------- Date: 2000-Sep-30 17:10 By: fdrake Comment: Assigned to Ken to pass along to Jim Fulton -- please mark this "Accepted" and assign to Martin to approve this for checkin, or update a revised patch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101721&group_id=5470 From noreply@sourceforge.net Sun Oct 1 08:55:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 1 Oct 2000 00:55:33 -0700 Subject: [Patches] [Patch #101730] Add initial static support for Darwin/MacOSX Message-ID: <200010010755.AAA27157@bush.i.sourceforge.net> Patch #101730 has been updated. Project: Category: Build Status: Open Summary: Add initial static support for Darwin/MacOSX ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101730&group_id=5470 From noreply@sourceforge.net Sun Oct 1 18:53:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 1 Oct 2000 10:53:45 -0700 Subject: [Patches] [Patch #101724] Fix for 115714: Don't rename Tkinter to Tk Message-ID: <200010011753.KAA17065@bush.i.sourceforge.net> Patch #101724 has been updated. Project: Category: Tkinter Status: Closed Summary: Fix for 115714: Don't rename Tkinter to Tk Follow-Ups: Date: 2000-Sep-30 17:06 By: fdrake Comment: Don't add the comment about not re-exporting the "Tk" name -- it doesn't make sense except as a historical comment; that should be in the checkin comment, not the source file. Please make Error a subclass of Exception; tracebacks will be slightly easier to read since the exception itself will name the module that raised it. Please make these changes and check it in. ------------------------------------------------------- Date: 2000-Oct-01 10:53 By: loewis Comment: Committed as version 1.2 of turtle.py, implementing Fred's comments. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101724&group_id=5470 From noreply@sourceforge.net Mon Oct 2 17:00:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 2 Oct 2000 09:00:04 -0700 Subject: [Patches] [Patch #101721] Fix for 115530/1: add closed attribute to cStringIO objects Message-ID: <200010021600.JAA31830@bush.i.sourceforge.net> Patch #101721 has been updated. Project: Category: None Status: Open Summary: Fix for 115530/1: add closed attribute to cStringIO objects Follow-Ups: Date: 2000-Sep-30 09:25 By: loewis Comment: I have updated the patch to also fix 115530. The only remaining difference to StringIO is that cStringIO.readline does not support a maxsize argument. To add this parameter, the C API of cStringIO must be changed, and in turn cPickle. Is such a correction desirable? ------------------------------------------------------- Date: 2000-Sep-30 17:10 By: fdrake Comment: Assigned to Ken to pass along to Jim Fulton -- please mark this "Accepted" and assign to Martin to approve this for checkin, or update a revised patch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101721&group_id=5470 From noreply@sourceforge.net Tue Oct 3 10:50:27 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 3 Oct 2000 02:50:27 -0700 Subject: [Patches] [Patch #101751] Make 0.0**-2.0 raise ValueError (fixes hi-pri bug 115831) Message-ID: <200010030950.CAA30596@delerium.i.sourceforge.net> Patch #101751 has been updated. Project: Category: core (C code) Status: Open Summary: Make 0.0**-2.0 raise ValueError (fixes hi-pri bug 115831) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101751&group_id=5470 From noreply@sourceforge.net Tue Oct 3 10:53:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 3 Oct 2000 02:53:09 -0700 Subject: [Patches] [Patch #101751] Make 0.0**-2.0 raise ValueError (fixes hi-pri bug 115831) Message-ID: <200010030953.CAA30722@delerium.i.sourceforge.net> Patch #101751 has been updated. Project: Category: core (C code) Status: Open Summary: Make 0.0**-2.0 raise ValueError (fixes hi-pri bug 115831) Follow-Ups: Date: 2000-Oct-03 02:53 By: ping Comment: This patch moves a couple of clauses for special cases of pow() (where the base or exponent are zero or the exponent is negative) so that they don't get missed. This patch also adds some tests to Lib/test/test_pow.py to ensure that any type of zero raised to any negative power raises a ValueError. Python 2.0b1 fails these tests as it stands; with the patch added, it passes. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101751&group_id=5470 From noreply@sourceforge.net Tue Oct 3 14:52:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 3 Oct 2000 06:52:53 -0700 Subject: [Patches] [Patch #101751] Make 0.0**-2.0 raise ValueError (fixes hi-pri bug 115831) Message-ID: <200010031352.GAA16006@bush.i.sourceforge.net> Patch #101751 has been updated. Project: Category: core (C code) Status: Open Summary: Make 0.0**-2.0 raise ValueError (fixes hi-pri bug 115831) Follow-Ups: Date: 2000-Oct-03 02:53 By: ping Comment: This patch moves a couple of clauses for special cases of pow() (where the base or exponent are zero or the exponent is negative) so that they don't get missed. This patch also adds some tests to Lib/test/test_pow.py to ensure that any type of zero raised to any negative power raises a ValueError. Python 2.0b1 fails these tests as it stands; with the patch added, it passes. ------------------------------------------------------- Date: 2000-Oct-03 06:52 By: gvanrossum Comment: For Tim to review. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101751&group_id=5470 From noreply@sourceforge.net Tue Oct 3 16:59:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 3 Oct 2000 08:59:03 -0700 Subject: [Patches] [Patch #101730] Add initial static support for Darwin/MacOSX Message-ID: <200010031559.IAA21380@bush.i.sourceforge.net> Patch #101730 has been updated. Project: Category: Build Status: Open Summary: Add initial static support for Darwin/MacOSX Follow-Ups: Date: 2000-Oct-03 08:59 By: fdrake Comment: Superficially this looks fine to me, but I don't have a Darwin box to check it out on. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101730&group_id=5470 From noreply@sourceforge.net Tue Oct 3 17:43:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 3 Oct 2000 09:43:07 -0700 Subject: [Patches] [Patch #101753] exception bugfix for gcmodule.c Message-ID: <200010031643.JAA15026@delerium.i.sourceforge.net> Patch #101753 has been updated. Project: Category: core (C code) Status: Open Summary: exception bugfix for gcmodule.c ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101753&group_id=5470 From noreply@sourceforge.net Tue Oct 3 17:54:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 3 Oct 2000 09:54:05 -0700 Subject: [Patches] [Patch #101753] exception bugfix for gcmodule.c Message-ID: <200010031654.JAA15557@delerium.i.sourceforge.net> Patch #101753 has been updated. Project: Category: core (C code) Status: Open Summary: exception bugfix for gcmodule.c Follow-Ups: Date: 2000-Oct-03 09:54 By: nascheme Comment: Don't start collection if an exception has been raised otherwise the collector will think that it caused the error. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101753&group_id=5470 From noreply@sourceforge.net Wed Oct 4 08:06:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 4 Oct 2000 00:06:31 -0700 Subject: [Patches] [Patch #101753] exception bugfix for gcmodule.c Message-ID: <200010040706.AAA16054@delerium.i.sourceforge.net> Patch #101753 has been updated. Project: Category: core (C code) Status: Open Summary: exception bugfix for gcmodule.c Follow-Ups: Date: 2000-Oct-03 09:54 By: nascheme Comment: Don't start collection if an exception has been raised otherwise the collector will think that it caused the error. ------------------------------------------------------- Date: 2000-Oct-04 00:06 By: loewis Comment: An interesting bug, and an interesting patch... How many times is _PyGC_Insert typically invoked before the exception is cleared (e.g. in your test cases)? If that is "often", would it make sense to temporarily increase the threshold0 to delay collection? e.g. static int extra_threshold = 0; if(allocated > threshold0+extra_threshold ...){ if(PyErr_Occurred()) extra_threshold += threshold0 / 10; /* number picked arbitrarily */ else{ extra_threshold = 0; collecting++; ... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101753&group_id=5470 From noreply@sourceforge.net Wed Oct 4 12:52:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 4 Oct 2000 04:52:46 -0700 Subject: [Patches] [Patch #101753] exception bugfix for gcmodule.c Message-ID: <200010041152.EAA01266@bush.i.sourceforge.net> Patch #101753 has been updated. Project: Category: core (C code) Status: Open Summary: exception bugfix for gcmodule.c Follow-Ups: Date: 2000-Oct-03 09:54 By: nascheme Comment: Don't start collection if an exception has been raised otherwise the collector will think that it caused the error. ------------------------------------------------------- Date: 2000-Oct-04 00:06 By: loewis Comment: An interesting bug, and an interesting patch... How many times is _PyGC_Insert typically invoked before the exception is cleared (e.g. in your test cases)? If that is "often", would it make sense to temporarily increase the threshold0 to delay collection? e.g. static int extra_threshold = 0; if(allocated > threshold0+extra_threshold ...){ if(PyErr_Occurred()) extra_threshold += threshold0 / 10; /* number picked arbitrarily */ else{ extra_threshold = 0; collecting++; ... ------------------------------------------------------- Date: 2000-Oct-04 04:52 By: nascheme Comment: I expect this bug would be triggered extremely rarely with the default threshold0. I found it while testing with threshold0 = 1. If the user changed the threshold then I don't think its up to the GC to increase it. Also, I don't think the extra complexity is worth it. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101753&group_id=5470 From noreply@sourceforge.net Wed Oct 4 17:25:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 4 Oct 2000 09:25:41 -0700 Subject: [Patches] [Patch #101753] exception bugfix for gcmodule.c Message-ID: <200010041625.JAA12192@bush.i.sourceforge.net> Patch #101753 has been updated. Project: Category: core (C code) Status: Closed Summary: exception bugfix for gcmodule.c Follow-Ups: Date: 2000-Oct-03 09:54 By: nascheme Comment: Don't start collection if an exception has been raised otherwise the collector will think that it caused the error. ------------------------------------------------------- Date: 2000-Oct-04 00:06 By: loewis Comment: An interesting bug, and an interesting patch... How many times is _PyGC_Insert typically invoked before the exception is cleared (e.g. in your test cases)? If that is "often", would it make sense to temporarily increase the threshold0 to delay collection? e.g. static int extra_threshold = 0; if(allocated > threshold0+extra_threshold ...){ if(PyErr_Occurred()) extra_threshold += threshold0 / 10; /* number picked arbitrarily */ else{ extra_threshold = 0; collecting++; ... ------------------------------------------------------- Date: 2000-Oct-04 04:52 By: nascheme Comment: I expect this bug would be triggered extremely rarely with the default threshold0. I found it while testing with threshold0 = 1. If the user changed the threshold then I don't think its up to the GC to increase it. Also, I don't think the extra complexity is worth it. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101753&group_id=5470 From noreply@sourceforge.net Wed Oct 4 17:26:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 4 Oct 2000 09:26:24 -0700 Subject: [Patches] [Patch #101699] GC fixes for malloc() == NULL Message-ID: <200010041626.JAA12211@bush.i.sourceforge.net> Patch #101699 has been updated. Project: Category: core (C code) Status: Closed Summary: GC fixes for malloc() == NULL Follow-Ups: Date: 2000-Sep-28 16:38 By: nascheme Comment: I would like some comments on this patch before I apply it. First, there must be a matching PyObject_GC_Fini() for every PyObject_GC_Init(). Second of all, between the Init and Fini calls, all pointers in the object struct followed by tp_recurse must be valid. GC can be triggered at wierd times. The problem with classobject.c was that if PyDict_New() failed, PyObject_DEL() was used to free the instance (which does not call PyObject_GC_Fini()). The problem with cPickle.c was that if PyDict_New() failed, Py_DECREF() was called to free the instance. Py_DECREF() will call instance_dealloc() which calls PyObject_GC_Fini(). ------------------------------------------------------- Date: 2000-Sep-29 09:25 By: fdrake Comment: Assigned to Jeremy since he knows the GC stuff pretty well. ------------------------------------------------------- Date: 2000-Oct-04 09:26 By: nascheme Comment: Applied. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101699&group_id=5470 From noreply@sourceforge.net Wed Oct 4 17:28:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 4 Oct 2000 09:28:28 -0700 Subject: [Patches] [Patch #101753] exception bugfix for gcmodule.c Message-ID: <200010041628.JAA12241@bush.i.sourceforge.net> Patch #101753 has been updated. Project: Category: core (C code) Status: Closed Summary: exception bugfix for gcmodule.c Follow-Ups: Date: 2000-Oct-03 09:54 By: nascheme Comment: Don't start collection if an exception has been raised otherwise the collector will think that it caused the error. ------------------------------------------------------- Date: 2000-Oct-04 00:06 By: loewis Comment: An interesting bug, and an interesting patch... How many times is _PyGC_Insert typically invoked before the exception is cleared (e.g. in your test cases)? If that is "often", would it make sense to temporarily increase the threshold0 to delay collection? e.g. static int extra_threshold = 0; if(allocated > threshold0+extra_threshold ...){ if(PyErr_Occurred()) extra_threshold += threshold0 / 10; /* number picked arbitrarily */ else{ extra_threshold = 0; collecting++; ... ------------------------------------------------------- Date: 2000-Oct-04 04:52 By: nascheme Comment: I expect this bug would be triggered extremely rarely with the default threshold0. I found it while testing with threshold0 = 1. If the user changed the threshold then I don't think its up to the GC to increase it. Also, I don't think the extra complexity is worth it. ------------------------------------------------------- Date: 2000-Oct-04 09:28 By: nascheme Comment: Applied. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101753&group_id=5470 From noreply@sourceforge.net Wed Oct 4 18:51:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 4 Oct 2000 10:51:42 -0700 Subject: [Patches] [Patch #101772] __MWERKS__ != BeOS in thread.c Message-ID: <200010041751.KAA08987@delerium.i.sourceforge.net> Patch #101772 has been updated. Project: Category: core (C code) Status: Open Summary: __MWERKS__ != BeOS in thread.c ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101772&group_id=5470 From noreply@sourceforge.net Wed Oct 4 18:54:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 4 Oct 2000 10:54:09 -0700 Subject: [Patches] [Patch #101773] BeOS PPC lacks fseeko, but isn't MS Windows Message-ID: <200010041754.KAA09043@delerium.i.sourceforge.net> Patch #101773 has been updated. Project: Category: core (C code) Status: Open Summary: BeOS PPC lacks fseeko, but isn't MS Windows ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101773&group_id=5470 From noreply@sourceforge.net Wed Oct 4 19:01:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 4 Oct 2000 11:01:58 -0700 Subject: [Patches] [Patch #101774] revise BeOS build Message-ID: <200010041801.LAA09406@delerium.i.sourceforge.net> Patch #101774 has been updated. Project: Category: Build Status: Open Summary: revise BeOS build ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101774&group_id=5470 From noreply@sourceforge.net Wed Oct 4 19:03:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 4 Oct 2000 11:03:54 -0700 Subject: [Patches] [Patch #101775] revise BeOS build Message-ID: <200010041803.LAA09470@delerium.i.sourceforge.net> Patch #101775 has been updated. Project: Category: Build Status: Open Summary: revise BeOS build ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101775&group_id=5470 From noreply@sourceforge.net Wed Oct 4 19:05:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 4 Oct 2000 11:05:56 -0700 Subject: [Patches] [Patch #101776] revise BeOS build Message-ID: <200010041805.LAA09600@delerium.i.sourceforge.net> Patch #101776 has been updated. Project: Category: Build Status: Open Summary: revise BeOS build ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101776&group_id=5470 From noreply@sourceforge.net Wed Oct 4 19:07:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 4 Oct 2000 11:07:31 -0700 Subject: [Patches] [Patch #101777] revise BeOS build Message-ID: <200010041807.LAA09633@delerium.i.sourceforge.net> Patch #101777 has been updated. Project: Category: Build Status: Open Summary: revise BeOS build ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101777&group_id=5470 From noreply@sourceforge.net Wed Oct 4 19:12:27 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 4 Oct 2000 11:12:27 -0700 Subject: [Patches] [Patch #101778] revise BeOS build Message-ID: <200010041812.LAA09882@delerium.i.sourceforge.net> Patch #101778 has been updated. Project: Category: Build Status: Open Summary: revise BeOS build ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101778&group_id=5470 From noreply@sourceforge.net Wed Oct 4 19:15:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 4 Oct 2000 11:15:59 -0700 Subject: [Patches] [Patch #101779] revise BeOS build Message-ID: <200010041815.LAA10075@delerium.i.sourceforge.net> Patch #101779 has been updated. Project: Category: Build Status: Open Summary: revise BeOS build ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101779&group_id=5470 From noreply@sourceforge.net Wed Oct 4 19:17:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 4 Oct 2000 11:17:36 -0700 Subject: [Patches] [Patch #101780] BeOS/linkmodule missing VERSION Message-ID: <200010041817.LAA10113@delerium.i.sourceforge.net> Patch #101780 has been updated. Project: Category: demos and tools Status: Open Summary: BeOS/linkmodule missing VERSION ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101780&group_id=5470 From noreply@sourceforge.net Wed Oct 4 19:18:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 4 Oct 2000 11:18:23 -0700 Subject: [Patches] [Patch #101773] BeOS PPC lacks fseeko, but isn't MS Windows Message-ID: <200010041818.LAA10184@delerium.i.sourceforge.net> Patch #101773 has been updated. Project: Category: core (C code) Status: Open Summary: BeOS PPC lacks fseeko, but isn't MS Windows Follow-Ups: Date: 2000-Oct-04 11:18 By: tmick Comment: This is similar to a recent NetBSD 1.4.2 problem (cf: http://sourceforge.net/bugs/?func=detailbug&bug_id=112289&group_id=5470) The problem: NetBSD 1.4.2 and now I think BeOS pass the configure test for HAVE_LARGEFILE_SUPPORT but neither defines either fseeko() or fseek64() as required by the Single Unix Specification. That sucks. Question: What is this _fseek() in youy patch? This is a BeOS specific thing (sigh) I presume? Does it support large files, or pretend to? You can tell by the type of the second argument (the offset). If it is 'off_t' then it presumes to support largefiles. If it is 'long' then it does not. How is _fseek() different from fseek() on BeOS? Right Answer (tm): If this _fseek() does *not* support largefiles then I *think* the right answer is to change the HAVE_LARGEFILE_SUUPORT test such that it is *false* for NetBSD 1.4.2 and BeOS. I don't have the time (or a box to test this on) to try to get the right answer, though. So fat lot of good this comment is. It might be preferable to copy the NetBSD/OpenBSD patch (search NetBSD in the same file). Add __BEOS__. Does that work then? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101773&group_id=5470 From noreply@sourceforge.net Wed Oct 4 19:19:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 4 Oct 2000 11:19:10 -0700 Subject: [Patches] [Patch #101781] BeOS regen Message-ID: <200010041819.LAA10187@delerium.i.sourceforge.net> Patch #101781 has been updated. Project: Category: Build Status: Open Summary: BeOS regen ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101781&group_id=5470 From donn@u.washington.edu Wed Oct 4 19:51:06 2000 From: donn@u.washington.edu (Donn Cave) Date: Wed, 4 Oct 2000 11:51:06 -0700 (PDT) Subject: [Patches] Re: [Patch #101773] BeOS PPC lacks fseeko, but isn't MS Windows In-Reply-To: <200010041818.LAA10184@delerium.i.sourceforge.net> Message-ID: | By: tmick | | Comment: | This is similar to a recent NetBSD 1.4.2 problem (cf: http://sourceforge.net/bugs/?func=detailbug&bug_id=112289&group_id=5470) | | The problem: | NetBSD 1.4.2 and now I think BeOS pass the configure test for | HAVE_LARGEFILE_SUPPORT but neither defines either fseeko() or fseek64() | as required by the Single Unix Specification. That sucks. Maybe what sucks is the test for large file support. My casual impression is that it doesn't test anything of the sort, it just notices that the necessary 64 bit typedef exists. | Question: | What is this _fseek() in youy patch? This is a BeOS specific thing (sigh) | I presume? Does it support large files, or pretend to? You can tell by the | type of the second argument (the offset). If it is 'off_t' then it presumes | to support largefiles. If it is 'long' then it does not. How is _fseek() | different from fseek() on BeOS? By this criterion, it supports large files. fseek() is "long", _fseek() is "long long" (fpos_t). | Right Answer (tm): | If this _fseek() does *not* support largefiles then I *think* the right | answer is to change the HAVE_LARGEFILE_SUUPORT test such that it is | *false* for NetBSD 1.4.2 and BeOS. That's fine with me. I really doubt that it is supported in a useful sense (like, you can manipulate large files). This mod is actually for only BeOS PPC, which is an obsolescent branch of the hardware platforms that uses MetroWerks C compiler. On the current Intel platform, fseeko exists - in the library, but uncharacteristically seems to be missing from the includes. I doubt they are really any different from fseek. My objective is only to get it to compile. | It might be preferable to copy the NetBSD/OpenBSD patch (search NetBSD | in the same file). Add __BEOS__. Does that work then? In theory I believe it would. It seems rather complex though - I mean, we apparently have an fseeko-alike that we can just call. Donn Cave, donn@oz.net From donn@u.washington.edu Wed Oct 4 20:09:45 2000 From: donn@u.washington.edu (Donn Cave) Date: Wed, 4 Oct 2000 12:09:45 -0700 (PDT) Subject: [Patches] Re: [Patch #101774] revise BeOS build In-Reply-To: <200010041801.LAA09406@delerium.i.sourceforge.net> Message-ID: If I can add some notes on this and the following about six patches - I know this is pretty damned late in the game for 2.0. If it's too late for you folks to contemplate changes like this in total comfort, then it's OK. I can get a patch kit to most people who would need it. I don't know what has happened to Chris Herborth. I mailed him about this last week and haven't heard anything. The stuff he cooked up wasn't making it. There was one little nuisance, his dl_export.h file would get installed in the wrong directory - not in the include directory. The other main problem was that the build didn't work on the old PPC (Macintosh and BeBox) platform, which uses a Metrowerks compiler and linker. I assume it was something about his ar-fake, and despite its name my feeling is that it made overly heroic efforts to simulate "ar". I replace ar-fake with something so simple it's goofy, just a filesystem directory. I eliminate dl_config.h and replace it with hairy command line -D flags - on the PPC side, only, the Intel platform doesn't need this stuff at all. That basically the story. Happy to entertain other questions or suggestions. From noreply@sourceforge.net Wed Oct 4 20:24:51 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 4 Oct 2000 12:24:51 -0700 Subject: [Patches] [Patch #101782] Enhances 1.6 compiler to raise 'proper' SyntaxErrors Message-ID: <200010041924.MAA19561@bush.i.sourceforge.net> Patch #101782 has been updated. Project: Category: Parser/Compiler Status: Open Summary: Enhances 1.6 compiler to raise 'proper' SyntaxErrors ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101782&group_id=5470 From noreply@sourceforge.net Wed Oct 4 20:29:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 4 Oct 2000 12:29:35 -0700 Subject: [Patches] [Patch #101782] Enhances 1.6 compiler to raise 'proper' SyntaxErrors Message-ID: <200010041929.MAA19747@bush.i.sourceforge.net> Patch #101782 has been updated. Project: Category: Parser/Compiler Status: Open Summary: Enhances 1.6 compiler to raise 'proper' SyntaxErrors Follow-Ups: Date: 2000-Oct-04 12:29 By: Roman_Sulzhyk Comment: Hello: There's a problem with the compiler.c (which persists in 2.0 also) which means it raises 'old style' SyntaxErrors, which could not be formatted properly. I mentioned this to Guido during the last conference, and he said it can best be done by moving parts of the 'linecache' functionality to core python, or something along those lines. Well, I've put together something which is not so far-fetching, but plugs this hole. The only time it reverts to the 'old style' compile error is when the input file is not a regular file (like stdin), since the line information is lost at that point - don't think parser.c saves it anywhere. Tell me what you think - should I port it to 2.0, or just drop it altogether if it's not needed. Thanks, Roman ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101782&group_id=5470 From noreply@sourceforge.net Wed Oct 4 20:29:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 4 Oct 2000 12:29:35 -0700 Subject: [Patches] [Patch #101782] Enhances 1.6 compiler to raise 'proper' SyntaxErrors Message-ID: <200010041929.MAA19744@bush.i.sourceforge.net> Patch #101782 has been updated. Project: Category: Parser/Compiler Status: Open Summary: Enhances 1.6 compiler to raise 'proper' SyntaxErrors Follow-Ups: Date: 2000-Oct-04 12:29 By: Roman_Sulzhyk Comment: Hello: There's a problem with the compiler.c (which persists in 2.0 also) which means it raises 'old style' SyntaxErrors, which could not be formatted properly. I mentioned this to Guido during the last conference, and he said it can best be done by moving parts of the 'linecache' functionality to core python, or something along those lines. Well, I've put together something which is not so far-fetching, but plugs this hole. The only time it reverts to the 'old style' compile error is when the input file is not a regular file (like stdin), since the line information is lost at that point - don't think parser.c saves it anywhere. Tell me what you think - should I port it to 2.0, or just drop it altogether if it's not needed. Thanks, Roman ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101782&group_id=5470 From trentm@ActiveState.com Wed Oct 4 21:46:10 2000 From: trentm@ActiveState.com (Trent Mick) Date: Wed, 4 Oct 2000 13:46:10 -0700 Subject: [Patches] Re: [Patch #101773] BeOS PPC lacks fseeko, but isn't MS Windows In-Reply-To: ; from donn@u.washington.edu on Wed, Oct 04, 2000 at 11:51:06AM -0700 References: <200010041818.LAA10184@delerium.i.sourceforge.net> Message-ID: <20001004134610.D1657@ActiveState.com> On Wed, Oct 04, 2000 at 11:51:06AM -0700, Donn Cave wrote: > | NetBSD 1.4.2 and now I think BeOS pass the configure test for > | HAVE_LARGEFILE_SUPPORT but neither defines either fseeko() or fseek64() > | as required by the Single Unix Specification. That sucks. > > Maybe what sucks is the test for large file support. My casual impression I agree, you are right. > My objective is only to get it to compile. Very fair. > This mod is actually for > only BeOS PPC, which is an obsolescent branch of the hardware platforms > that uses MetroWerks C compiler. On the current Intel platform, fseeko > exists - in the library, but uncharacteristically seems to be missing > from the includes. I doubt they are really any different from fseek. > > | It might be preferable to copy the NetBSD/OpenBSD patch (search NetBSD > | in the same file). Add __BEOS__. Does that work then? > > In theory I believe it would. It seems rather complex though - > I mean, we apparently have an fseeko-alike that we can just call. > Yes, again, you are right that that would be complex. If _fseek is equivalent to fseeko then it should follow the same path through the code as fseeko. Maybe then #define a FSEEKO, something like #ifdef __BEOS__ /* can this be made to specify the BeOS PPC branch specifically? */ #define FSEEKO _fseek #else #define FSEEKO fseeko #endif Would you be able to try that? Trent -- Trent Mick TrentM@ActiveState.com From donn@u.washington.edu Thu Oct 5 01:08:52 2000 From: donn@u.washington.edu (Donn Cave) Date: Wed, 4 Oct 2000 17:08:52 -0700 (PDT) Subject: [Patches] Re: [Patch #101773] BeOS PPC lacks fseeko, but isn't MS Windows In-Reply-To: <20001004134610.D1657@ActiveState.com> Message-ID: | Yes, again, you are right that that would be complex. If _fseek is equivalent | to fseeko then it should follow the same path through the code as fseeko. | Maybe then #define a FSEEKO, something like | | #ifdef __BEOS__ | /* can this be made to specify the BeOS PPC branch specifically? */ | #define FSEEKO _fseek | #else | #define FSEEKO fseeko | #endif | | Would you be able to try that? It will work. The platform would be #if defined(__BEOS__) && defined(__MWERKS__) (use _fseek()) If you like, you can even use fseeko: #if !defined(HAVE_FSEEKO) && defined(__BEOS__) # define fseeko _fseek # define HAVE_FSEEKO 1 #endif Incidentally, after some tests, I am more inclined to think BeOS does support these functions in a meaningful way. We don't have "holes", so I can't write at 64 bit locations in any file, but I do get "No space left on device", and I take that as evidence that they're not just ignoring the high bits of the parameter. Donn Cave, donn@oz.net From noreply@sourceforge.net Thu Oct 5 07:40:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 4 Oct 2000 23:40:12 -0700 Subject: [Patches] [Patch #101782] Enhances 1.6 compiler to raise 'proper' SyntaxErrors Message-ID: <200010050640.XAA11970@bush.i.sourceforge.net> Patch #101782 has been updated. Project: Category: Parser/Compiler Status: Postponed Summary: Enhances 1.6 compiler to raise 'proper' SyntaxErrors Follow-Ups: Date: 2000-Oct-04 12:29 By: Roman_Sulzhyk Comment: Hello: There's a problem with the compiler.c (which persists in 2.0 also) which means it raises 'old style' SyntaxErrors, which could not be formatted properly. I mentioned this to Guido during the last conference, and he said it can best be done by moving parts of the 'linecache' functionality to core python, or something along those lines. Well, I've put together something which is not so far-fetching, but plugs this hole. The only time it reverts to the 'old style' compile error is when the input file is not a regular file (like stdin), since the line information is lost at that point - don't think parser.c saves it anywhere. Tell me what you think - should I port it to 2.0, or just drop it altogether if it's not needed. Thanks, Roman ------------------------------------------------------- Date: 2000-Oct-04 23:40 By: fdrake Comment: This needs to be ported to the latest CVS version before being considered for implementation (but discussion of the feature is welcome!). This cannot be considered for inclusion in 2.0 since we're in feature freeze already, and are only fixing bugs at this point. This can be considered for 2.1. Marking as postponed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101782&group_id=5470 From noreply@sourceforge.net Thu Oct 5 11:57:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 5 Oct 2000 03:57:12 -0700 Subject: [Patches] [Patch #101676] Detect conflicting Python DLL on module import under Windows Message-ID: <200010051057.DAA21725@bush.i.sourceforge.net> Patch #101676 has been updated. Project: Category: Windows Status: Closed Summary: Detect conflicting Python DLL on module import under Windows Follow-Ups: Date: 2000-Sep-26 22:49 By: db3l Comment: This patch is an attempt to provide similar functionality to an earlier proposed patch (101651) but addressing Mark's concern about a process having two DLLs loaded explicitly. This patch parses the actual module import table after the module has been loaded into memory to determine which Python DLL (identified by a "python" prefix followed by just numbers) is loaded specifically by the module as opposed to just being in the process space, and compares that to the current Python version, complaining (and identifying the referenced DLL in the error) if there is a mismatch. ------------------------------------------------------- Date: 2000-Sep-28 12:16 By: fdrake Comment: Assigned to Mark Hammond since Tim's on vacation. ------------------------------------------------------- Date: 2000-Oct-05 03:57 By: mhammond Comment: The code looks good, and tests perfectly for me with 1.5 and 1.6 extensions. Applied as revision 2.7 of Python/dynload_win.c - thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101676&group_id=5470 From noreply@sourceforge.net Thu Oct 5 15:37:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 5 Oct 2000 07:37:49 -0700 Subject: [Patches] [Patch #101774] revise BeOS build Message-ID: <200010051437.HAA22362@delerium.i.sourceforge.net> Patch #101774 has been updated. Project: Category: Build Status: Deleted Summary: revise BeOS build ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101774&group_id=5470 From noreply@sourceforge.net Thu Oct 5 15:37:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 5 Oct 2000 07:37:50 -0700 Subject: [Patches] [Patch #101777] revise BeOS build Message-ID: <200010051437.HAA22371@delerium.i.sourceforge.net> Patch #101777 has been updated. Project: Category: Build Status: Deleted Summary: revise BeOS build ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101777&group_id=5470 From noreply@sourceforge.net Thu Oct 5 15:37:51 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 5 Oct 2000 07:37:51 -0700 Subject: [Patches] [Patch #101778] revise BeOS build Message-ID: <200010051437.HAA22375@delerium.i.sourceforge.net> Patch #101778 has been updated. Project: Category: Build Status: Deleted Summary: revise BeOS build ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101778&group_id=5470 From noreply@sourceforge.net Thu Oct 5 15:37:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 5 Oct 2000 07:37:49 -0700 Subject: [Patches] [Patch #101775] revise BeOS build Message-ID: <200010051437.HAA22365@delerium.i.sourceforge.net> Patch #101775 has been updated. Project: Category: Build Status: Deleted Summary: revise BeOS build ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101775&group_id=5470 From noreply@sourceforge.net Thu Oct 5 15:37:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 5 Oct 2000 07:37:50 -0700 Subject: [Patches] [Patch #101776] revise BeOS build Message-ID: <200010051437.HAA22368@delerium.i.sourceforge.net> Patch #101776 has been updated. Project: Category: Build Status: Deleted Summary: revise BeOS build ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101776&group_id=5470 From noreply@sourceforge.net Thu Oct 5 15:38:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 5 Oct 2000 07:38:47 -0700 Subject: [Patches] [Patch #101772] __MWERKS__ != BeOS in thread.c Message-ID: <200010051438.HAA22404@delerium.i.sourceforge.net> Patch #101772 has been updated. Project: Category: Build Status: Open Summary: __MWERKS__ != BeOS in thread.c ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101772&group_id=5470 From noreply@sourceforge.net Thu Oct 5 15:38:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 5 Oct 2000 07:38:47 -0700 Subject: [Patches] [Patch #101773] BeOS PPC lacks fseeko, but isn't MS Windows Message-ID: <200010051438.HAA22407@delerium.i.sourceforge.net> Patch #101773 has been updated. Project: Category: Build Status: Open Summary: BeOS PPC lacks fseeko, but isn't MS Windows Follow-Ups: Date: 2000-Oct-04 11:18 By: tmick Comment: This is similar to a recent NetBSD 1.4.2 problem (cf: http://sourceforge.net/bugs/?func=detailbug&bug_id=112289&group_id=5470) The problem: NetBSD 1.4.2 and now I think BeOS pass the configure test for HAVE_LARGEFILE_SUPPORT but neither defines either fseeko() or fseek64() as required by the Single Unix Specification. That sucks. Question: What is this _fseek() in youy patch? This is a BeOS specific thing (sigh) I presume? Does it support large files, or pretend to? You can tell by the type of the second argument (the offset). If it is 'off_t' then it presumes to support largefiles. If it is 'long' then it does not. How is _fseek() different from fseek() on BeOS? Right Answer (tm): If this _fseek() does *not* support largefiles then I *think* the right answer is to change the HAVE_LARGEFILE_SUUPORT test such that it is *false* for NetBSD 1.4.2 and BeOS. I don't have the time (or a box to test this on) to try to get the right answer, though. So fat lot of good this comment is. It might be preferable to copy the NetBSD/OpenBSD patch (search NetBSD in the same file). Add __BEOS__. Does that work then? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101773&group_id=5470 From noreply@sourceforge.net Thu Oct 5 15:38:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 5 Oct 2000 07:38:48 -0700 Subject: [Patches] [Patch #101779] revise BeOS build Message-ID: <200010051438.HAA22410@delerium.i.sourceforge.net> Patch #101779 has been updated. Project: Category: Build Status: Open Summary: revise BeOS build ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101779&group_id=5470 From noreply@sourceforge.net Thu Oct 5 15:38:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 5 Oct 2000 07:38:48 -0700 Subject: [Patches] [Patch #101780] BeOS/linkmodule missing VERSION Message-ID: <200010051438.HAA22413@delerium.i.sourceforge.net> Patch #101780 has been updated. Project: Category: Build Status: Open Summary: BeOS/linkmodule missing VERSION ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101780&group_id=5470 From noreply@sourceforge.net Thu Oct 5 15:38:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 5 Oct 2000 07:38:49 -0700 Subject: [Patches] [Patch #101781] BeOS regen Message-ID: <200010051438.HAA22416@delerium.i.sourceforge.net> Patch #101781 has been updated. Project: Category: Build Status: Open Summary: BeOS regen ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101781&group_id=5470 From noreply@sourceforge.net Thu Oct 5 19:00:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 5 Oct 2000 11:00:37 -0700 Subject: [Patches] [Patch #101730] Add initial static support for Darwin/MacOSX Message-ID: <200010051800.LAA06303@bush.i.sourceforge.net> Patch #101730 has been updated. Project: Category: Build Status: Closed Summary: Add initial static support for Darwin/MacOSX Follow-Ups: Date: 2000-Oct-03 08:59 By: fdrake Comment: Superficially this looks fine to me, but I don't have a Darwin box to check it out on. ------------------------------------------------------- Date: 2000-Oct-05 11:00 By: gvanrossum Comment: Checked in. Note that somehow you had changed tabs into spaces, which caused some problems applying the diff. Oh well. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101730&group_id=5470 From noreply@sourceforge.net Thu Oct 5 19:43:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 5 Oct 2000 11:43:43 -0700 Subject: [Patches] [Patch #101730] Add initial static support for Darwin/MacOSX Message-ID: <200010051843.LAA08050@bush.i.sourceforge.net> Patch #101730 has been updated. Project: Category: Build Status: Closed Summary: Add initial static support for Darwin/MacOSX Follow-Ups: Date: 2000-Oct-03 08:59 By: fdrake Comment: Superficially this looks fine to me, but I don't have a Darwin box to check it out on. ------------------------------------------------------- Date: 2000-Oct-05 11:00 By: gvanrossum Comment: Checked in. Note that somehow you had changed tabs into spaces, which caused some problems applying the diff. Oh well. ------------------------------------------------------- Date: 2000-Oct-05 11:43 By: gvanrossum Comment: Note that I didn't check this on Darwin/MaxOSX either. I'm just taking the patch at face value. I tested that ti didn't change anything on my Linux build. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101730&group_id=5470 From noreply@sourceforge.net Fri Oct 6 01:39:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 5 Oct 2000 17:39:00 -0700 Subject: [Patches] [Patch #101751] Make 0.0**-2.0 raise ValueError (fixes hi-pri bug 115831) Message-ID: <200010060039.RAA13609@delerium.i.sourceforge.net> Patch #101751 has been updated. Project: Category: core (C code) Status: Closed Summary: Make 0.0**-2.0 raise ValueError (fixes hi-pri bug 115831) Follow-Ups: Date: 2000-Oct-03 02:53 By: ping Comment: This patch moves a couple of clauses for special cases of pow() (where the base or exponent are zero or the exponent is negative) so that they don't get missed. This patch also adds some tests to Lib/test/test_pow.py to ensure that any type of zero raised to any negative power raises a ValueError. Python 2.0b1 fails these tests as it stands; with the patch added, it passes. ------------------------------------------------------- Date: 2000-Oct-03 06:52 By: gvanrossum Comment: For Tim to review. ------------------------------------------------------- Date: 2000-Oct-05 17:38 By: tim_one Comment: Closed. Checkin comment: SF bug 115831 and Ping's SF patch 101751, 0.0**-2.0 returns inf rather than raise ValueError. Checked in the patch as far as it went, but also changed all of ints, longs and floats to raise ZeroDivisionError instead when raising 0 to a negative number. This is what 754-inspired stds require, as the " true result" is an infinity obtained from finite operands, i.e. it's a singularity. Also changed float pow to not be so timid about using its square-and-multiply algorithm. Note that what math.pow does is unrelated to what builtin pow does, and will still vary by platform. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101751&group_id=5470 From noreply@sourceforge.net Fri Oct 6 02:02:14 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 5 Oct 2000 18:02:14 -0700 Subject: [Patches] [Patch #101713] Free extension DLLs' handles during the Py_Finalize() Message-ID: <200010060102.SAA22736@bush.i.sourceforge.net> Patch #101713 has been updated. Project: Category: Windows Status: Open Summary: Free extension DLLs' handles during the Py_Finalize() Follow-Ups: Date: 2000-Sep-29 12:09 By: Markovitch Comment: This patch is intended to fix the following problem: Python on Windows never frees DLLs loaded as extension. Whenever it's not a big problem when the interpreter is being used in a standart way, it becomes THE problem (or even a disaster) when the interpreter DLL is dynamically initialized/finalized from one process many times during single run. Moreover, even in case of single initialization there is a trap - DLLs loaded by mistake are unloaded only then a process finishes (e.g. suppose there is a foo.dll in the current directory and foo.dll is NOT a Python extension; "import foo" ends up with error, but foo.dll will be anging in process' address space!) This patch 1) frees a DLL handle in case of it has no proper initialization funcion 2) registers in an internal array all handles of successfully loaded dynamic extensions 2) frees all registered handles during Py_Finalize() Yakov Markovitch, markovitch@iso.ru ------------------------------------------------------- Date: 2000-Sep-30 17:01 By: fdrake Comment: Assigned to one of our Windows guys for review. ------------------------------------------------------- Date: 2000-Sep-30 17:01 By: fdrake Comment: Assigned to one of our Windows guys for review. ------------------------------------------------------- Date: 2000-Oct-05 18:02 By: tim_one Comment: Mark, you got anything to say about this? Can't say I've ever noticed a problem here. Note that "the patch" is actually a .zip archive, and it takes a little effort to sort out what's what. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101713&group_id=5470 From noreply@sourceforge.net Fri Oct 6 02:19:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 5 Oct 2000 18:19:29 -0700 Subject: [Patches] [Patch #101713] Free extension DLLs' handles during the Py_Finalize() Message-ID: <200010060119.SAA23390@bush.i.sourceforge.net> Patch #101713 has been updated. Project: Category: Windows Status: Postponed Summary: Free extension DLLs' handles during the Py_Finalize() Follow-Ups: Date: 2000-Sep-29 12:09 By: Markovitch Comment: This patch is intended to fix the following problem: Python on Windows never frees DLLs loaded as extension. Whenever it's not a big problem when the interpreter is being used in a standart way, it becomes THE problem (or even a disaster) when the interpreter DLL is dynamically initialized/finalized from one process many times during single run. Moreover, even in case of single initialization there is a trap - DLLs loaded by mistake are unloaded only then a process finishes (e.g. suppose there is a foo.dll in the current directory and foo.dll is NOT a Python extension; "import foo" ends up with error, but foo.dll will be anging in process' address space!) This patch 1) frees a DLL handle in case of it has no proper initialization funcion 2) registers in an internal array all handles of successfully loaded dynamic extensions 2) frees all registered handles during Py_Finalize() Yakov Markovitch, markovitch@iso.ru ------------------------------------------------------- Date: 2000-Sep-30 17:01 By: fdrake Comment: Assigned to one of our Windows guys for review. ------------------------------------------------------- Date: 2000-Sep-30 17:01 By: fdrake Comment: Assigned to one of our Windows guys for review. ------------------------------------------------------- Date: 2000-Oct-05 18:02 By: tim_one Comment: Mark, you got anything to say about this? Can't say I've ever noticed a problem here. Note that "the patch" is actually a .zip archive, and it takes a little effort to sort out what's what. ------------------------------------------------------- Date: 2000-Oct-05 18:19 By: mhammond Comment: I agree we should close handles that we can't use as extension modules. I am quite skeptical of the unloading of modules, tho. Python simply doesn't provide enough cleanup semantics to guarantee we are finished with the module at Py_Finalize() time. Indeed, extension modules are one main reason why Python often can not handle multiple Py_Initialize()/Py_Finalize() calls in the same process. I think that Python needs to grow module termination semantics. Something like, at Py_Finalize time: Try and find function "term_{module}" If function exists: call function free handle else: pass Thus - only modules that have gone to the trouble of providing a finalize function can be trusted to be unloaded. On one hand, the addition of the map means we _are_ in a better position for better finalization semantics on Windows. On the larger hand, module finalization semantics must be cross-platform anyway. So - while I acknowledge the problem, I don't believe this alone is a reasonable solution. Marking as postponed, and assigning back to Tim, so he can rule on the next step.... This came up a number of years ago, and Guido agreed "better" semantics were needed. Sounds like PEP material. I guess I _do_ care enough about this issue to own a PEP on it, as long as no-one needs the PEP finalized this year ;-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101713&group_id=5470 From noreply@sourceforge.net Fri Oct 6 04:42:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 5 Oct 2000 20:42:44 -0700 Subject: [Patches] [Patch #101801] Prevent possible buffer exploits under Windows Message-ID: <200010060342.UAA20006@delerium.i.sourceforge.net> Patch #101801 has been updated. Project: Category: Windows Status: Open Summary: Prevent possible buffer exploits under Windows ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101801&group_id=5470 From noreply@sourceforge.net Fri Oct 6 04:46:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 5 Oct 2000 20:46:46 -0700 Subject: [Patches] [Patch #101801] Prevent possible buffer exploits under Windows Message-ID: <200010060346.UAA20161@delerium.i.sourceforge.net> Patch #101801 has been updated. Project: Category: Windows Status: Open Summary: Prevent possible buffer exploits under Windows Follow-Ups: Date: 2000-Oct-05 20:46 By: mhammond Comment: Assigning to myself - will ask for review on python-dev, then checkin before RC release. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101801&group_id=5470 From noreply@sourceforge.net Fri Oct 6 04:56:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 5 Oct 2000 20:56:55 -0700 Subject: [Patches] [Patch #101802] Cygwin Fix -- missing tcp.h Message-ID: <200010060356.UAA29053@bush.i.sourceforge.net> Patch #101802 has been updated. Project: Category: Modules Status: Open Summary: Cygwin Fix -- missing tcp.h ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101802&group_id=5470 From noreply@sourceforge.net Fri Oct 6 05:49:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 5 Oct 2000 21:49:36 -0700 Subject: [Patches] [Patch #101804] Cygwin Fix -- missing tcp.h Message-ID: <200010060449.VAA22291@delerium.i.sourceforge.net> Patch #101804 has been updated. Project: Category: Modules Status: Open Summary: Cygwin Fix -- missing tcp.h ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101804&group_id=5470 From noreply@sourceforge.net Fri Oct 6 10:54:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 6 Oct 2000 02:54:34 -0700 Subject: [Patches] [Patch #101713] Free extension DLLs' handles during the Py_Finalize() Message-ID: <200010060954.CAA09780@bush.i.sourceforge.net> Patch #101713 has been updated. Project: Category: Windows Status: Postponed Summary: Free extension DLLs' handles during the Py_Finalize() Follow-Ups: Date: 2000-Sep-29 12:09 By: Markovitch Comment: This patch is intended to fix the following problem: Python on Windows never frees DLLs loaded as extension. Whenever it's not a big problem when the interpreter is being used in a standart way, it becomes THE problem (or even a disaster) when the interpreter DLL is dynamically initialized/finalized from one process many times during single run. Moreover, even in case of single initialization there is a trap - DLLs loaded by mistake are unloaded only then a process finishes (e.g. suppose there is a foo.dll in the current directory and foo.dll is NOT a Python extension; "import foo" ends up with error, but foo.dll will be anging in process' address space!) This patch 1) frees a DLL handle in case of it has no proper initialization funcion 2) registers in an internal array all handles of successfully loaded dynamic extensions 2) frees all registered handles during Py_Finalize() Yakov Markovitch, markovitch@iso.ru ------------------------------------------------------- Date: 2000-Sep-30 17:01 By: fdrake Comment: Assigned to one of our Windows guys for review. ------------------------------------------------------- Date: 2000-Sep-30 17:01 By: fdrake Comment: Assigned to one of our Windows guys for review. ------------------------------------------------------- Date: 2000-Oct-05 18:02 By: tim_one Comment: Mark, you got anything to say about this? Can't say I've ever noticed a problem here. Note that "the patch" is actually a .zip archive, and it takes a little effort to sort out what's what. ------------------------------------------------------- Date: 2000-Oct-05 18:19 By: mhammond Comment: I agree we should close handles that we can't use as extension modules. I am quite skeptical of the unloading of modules, tho. Python simply doesn't provide enough cleanup semantics to guarantee we are finished with the module at Py_Finalize() time. Indeed, extension modules are one main reason why Python often can not handle multiple Py_Initialize()/Py_Finalize() calls in the same process. I think that Python needs to grow module termination semantics. Something like, at Py_Finalize time: Try and find function "term_{module}" If function exists: call function free handle else: pass Thus - only modules that have gone to the trouble of providing a finalize function can be trusted to be unloaded. On one hand, the addition of the map means we _are_ in a better position for better finalization semantics on Windows. On the larger hand, module finalization semantics must be cross-platform anyway. So - while I acknowledge the problem, I don't believe this alone is a reasonable solution. Marking as postponed, and assigning back to Tim, so he can rule on the next step.... This came up a number of years ago, and Guido agreed "better" semantics were needed. Sounds like PEP material. I guess I _do_ care enough about this issue to own a PEP on it, as long as no-one needs the PEP finalized this year ;-) ------------------------------------------------------- Date: 2000-Oct-06 02:54 By: Markovitch Comment: Yes, I agree with Mark, but there is the other side of the problem. Let's suppose that we have an application that uses the interpreter through dynamic loading (I mean through the LoadLibrary). It isn't likely to be directly, but the application can load/unload some other DLL which, in turn, uses an embedded interpreter. Now after freeing this DLL the application has ALL extensions which was used by this DLL loaded! (Though it hasn't the interpreter embedded at all!) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101713&group_id=5470 From noreply@sourceforge.net Fri Oct 6 10:54:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 6 Oct 2000 02:54:34 -0700 Subject: [Patches] [Patch #101713] Free extension DLLs' handles during the Py_Finalize() Message-ID: <200010060954.CAA09783@bush.i.sourceforge.net> Patch #101713 has been updated. Project: Category: Windows Status: Postponed Summary: Free extension DLLs' handles during the Py_Finalize() Follow-Ups: Date: 2000-Sep-29 12:09 By: Markovitch Comment: This patch is intended to fix the following problem: Python on Windows never frees DLLs loaded as extension. Whenever it's not a big problem when the interpreter is being used in a standart way, it becomes THE problem (or even a disaster) when the interpreter DLL is dynamically initialized/finalized from one process many times during single run. Moreover, even in case of single initialization there is a trap - DLLs loaded by mistake are unloaded only then a process finishes (e.g. suppose there is a foo.dll in the current directory and foo.dll is NOT a Python extension; "import foo" ends up with error, but foo.dll will be anging in process' address space!) This patch 1) frees a DLL handle in case of it has no proper initialization funcion 2) registers in an internal array all handles of successfully loaded dynamic extensions 2) frees all registered handles during Py_Finalize() Yakov Markovitch, markovitch@iso.ru ------------------------------------------------------- Date: 2000-Sep-30 17:01 By: fdrake Comment: Assigned to one of our Windows guys for review. ------------------------------------------------------- Date: 2000-Sep-30 17:01 By: fdrake Comment: Assigned to one of our Windows guys for review. ------------------------------------------------------- Date: 2000-Oct-05 18:02 By: tim_one Comment: Mark, you got anything to say about this? Can't say I've ever noticed a problem here. Note that "the patch" is actually a .zip archive, and it takes a little effort to sort out what's what. ------------------------------------------------------- Date: 2000-Oct-05 18:19 By: mhammond Comment: I agree we should close handles that we can't use as extension modules. I am quite skeptical of the unloading of modules, tho. Python simply doesn't provide enough cleanup semantics to guarantee we are finished with the module at Py_Finalize() time. Indeed, extension modules are one main reason why Python often can not handle multiple Py_Initialize()/Py_Finalize() calls in the same process. I think that Python needs to grow module termination semantics. Something like, at Py_Finalize time: Try and find function "term_{module}" If function exists: call function free handle else: pass Thus - only modules that have gone to the trouble of providing a finalize function can be trusted to be unloaded. On one hand, the addition of the map means we _are_ in a better position for better finalization semantics on Windows. On the larger hand, module finalization semantics must be cross-platform anyway. So - while I acknowledge the problem, I don't believe this alone is a reasonable solution. Marking as postponed, and assigning back to Tim, so he can rule on the next step.... This came up a number of years ago, and Guido agreed "better" semantics were needed. Sounds like PEP material. I guess I _do_ care enough about this issue to own a PEP on it, as long as no-one needs the PEP finalized this year ;-) ------------------------------------------------------- Date: 2000-Oct-06 02:54 By: Markovitch Comment: Yes, I agree with Mark, but there is the other side of the problem. Let's suppose that we have an application that uses the interpreter through dynamic loading (I mean through the LoadLibrary). It isn't likely to be directly, but the application can load/unload some other DLL which, in turn, uses an embedded interpreter. Now after freeing this DLL the application has ALL extensions which was used by this DLL loaded! (Though it hasn't the interpreter embedded at all!) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101713&group_id=5470 From noreply@sourceforge.net Fri Oct 6 16:21:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 6 Oct 2000 08:21:39 -0700 Subject: [Patches] [Patch #101804] Cygwin Fix -- missing tcp.h Message-ID: <200010061521.IAA22135@bush.i.sourceforge.net> Patch #101804 has been updated. Project: Category: Modules Status: Deleted Summary: Cygwin Fix -- missing tcp.h Follow-Ups: Date: 2000-Oct-06 08:21 By: fdrake Comment: Closed -- this is a duplicate submission. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101804&group_id=5470 From noreply@sourceforge.net Fri Oct 6 16:37:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 6 Oct 2000 08:37:23 -0700 Subject: [Patches] [Patch #101802] Cygwin Fix -- missing tcp.h Message-ID: <200010061537.IAA22706@bush.i.sourceforge.net> Patch #101802 has been updated. Project: Category: Modules Status: Closed Summary: Cygwin Fix -- missing tcp.h Follow-Ups: Date: 2000-Oct-06 08:37 By: fdrake Comment: Checked in as Modules/socketmodule.c revision 1.128. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101802&group_id=5470 From noreply@sourceforge.net Fri Oct 6 16:51:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 6 Oct 2000 08:51:58 -0700 Subject: [Patches] [Patch #101772] __MWERKS__ != BeOS in thread.c Message-ID: <200010061551.IAA14365@delerium.i.sourceforge.net> Patch #101772 has been updated. Project: Category: Build Status: Closed Summary: __MWERKS__ != BeOS in thread.c Follow-Ups: Date: 2000-Oct-06 08:51 By: fdrake Comment: Checked in as Python/thread.c revision 2.36. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101772&group_id=5470 From noreply@sourceforge.net Fri Oct 6 16:58:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 6 Oct 2000 08:58:15 -0700 Subject: [Patches] [Patch #101780] BeOS/linkmodule missing VERSION Message-ID: <200010061558.IAA14643@delerium.i.sourceforge.net> Patch #101780 has been updated. Project: Category: Build Status: Closed Summary: BeOS/linkmodule missing VERSION Follow-Ups: Date: 2000-Oct-06 08:58 By: fdrake Comment: Checked in as BeOS/linkmodule revision 1.5. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101780&group_id=5470 From noreply@sourceforge.net Fri Oct 6 17:11:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 6 Oct 2000 09:11:47 -0700 Subject: [Patches] [Patch #101781] BeOS regen Message-ID: <200010061611.JAA15194@delerium.i.sourceforge.net> Patch #101781 has been updated. Project: Category: Build Status: Closed Summary: BeOS regen Follow-Ups: Date: 2000-Oct-06 09:11 By: fdrake Comment: Checked in after moving shared paths to variables, so the command lines are easier to parse for a human. This is Lib/plat-beos5/regen revision 1.1. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101781&group_id=5470 From noreply@sourceforge.net Fri Oct 6 17:17:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 6 Oct 2000 09:17:54 -0700 Subject: [Patches] [Patch #101779] revise BeOS build Message-ID: <200010061617.JAA15432@delerium.i.sourceforge.net> Patch #101779 has been updated. Project: Category: Build Status: Closed Summary: revise BeOS build Follow-Ups: Date: 2000-Oct-06 09:17 By: fdrake Comment: Checked in as BeOS/README revision 1.10. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101779&group_id=5470 From noreply@sourceforge.net Fri Oct 6 17:22:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 6 Oct 2000 09:22:00 -0700 Subject: [Patches] [Patch #101773] BeOS PPC lacks fseeko, but isn't MS Windows Message-ID: <200010061622.JAA15630@delerium.i.sourceforge.net> Patch #101773 has been updated. Project: Category: Build Status: Open Summary: BeOS PPC lacks fseeko, but isn't MS Windows Follow-Ups: Date: 2000-Oct-04 11:18 By: tmick Comment: This is similar to a recent NetBSD 1.4.2 problem (cf: http://sourceforge.net/bugs/?func=detailbug&bug_id=112289&group_id=5470) The problem: NetBSD 1.4.2 and now I think BeOS pass the configure test for HAVE_LARGEFILE_SUPPORT but neither defines either fseeko() or fseek64() as required by the Single Unix Specification. That sucks. Question: What is this _fseek() in youy patch? This is a BeOS specific thing (sigh) I presume? Does it support large files, or pretend to? You can tell by the type of the second argument (the offset). If it is 'off_t' then it presumes to support largefiles. If it is 'long' then it does not. How is _fseek() different from fseek() on BeOS? Right Answer (tm): If this _fseek() does *not* support largefiles then I *think* the right answer is to change the HAVE_LARGEFILE_SUUPORT test such that it is *false* for NetBSD 1.4.2 and BeOS. I don't have the time (or a box to test this on) to try to get the right answer, though. So fat lot of good this comment is. It might be preferable to copy the NetBSD/OpenBSD patch (search NetBSD in the same file). Add __BEOS__. Does that work then? ------------------------------------------------------- Date: 2000-Oct-06 09:22 By: fdrake Comment: I've asked Donn to respond to Trent's comments; waiting for a response before taking further action on this patch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101773&group_id=5470 From noreply@sourceforge.net Fri Oct 6 17:56:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 6 Oct 2000 09:56:15 -0700 Subject: [Patches] [Patch #101709] test_import to verify that .pyc files can be imported Message-ID: <200010061656.JAA25851@bush.i.sourceforge.net> Patch #101709 has been updated. Project: Category: core (C code) Status: Accepted Summary: test_import to verify that .pyc files can be imported Follow-Ups: Date: 2000-Sep-29 07:38 By: jhylton Comment: Will this detect the error in 2.0b2 and run on Windows? ------------------------------------------------------- Date: 2000-Oct-06 09:56 By: tim_one Comment: Accepted and assigned back to Jeremy, but unsure of which "error in 2.0b2" you're talking about. The Windows-specific magic number screwup? If so, yes: C:\Python20>python /code/python/dist/src/lib/test/test_import.py Traceback (most recent call last): File "/code/python/dist/src/lib/test/test_import.py", line 35, in ? raise ValueError, "import from .pyc/.pyo failed: %s" % err ValueError: import from .pyc/.pyo failed: Bad magic number in @test.pyc C:\Python20> One style nit: print >> f, "a = %s" % a print >> f, "b = %s" % b would be clearer as: print >> f, "a =", a print >> f, "b =", b ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101709&group_id=5470 From donn@u.washington.edu Fri Oct 6 18:31:48 2000 From: donn@u.washington.edu (Donn Cave) Date: Fri, 6 Oct 2000 10:31:48 -0700 Subject: [Patches] Re: [Patch #101773] BeOS PPC lacks fseeko, but isn't MS Windows Message-ID: <200010061731.KAA00952@mailhost1.u.washington.edu> | I've asked Donn to respond to Trent's comments; waiting for a response | before taking further action on this patch. I have actually corresponded with him on this one. I sent the mail to patches@python.org, and omitted noreply@sourceforge.net. He was getting them, but they didn't show up in the followups, should I have been sending to noreply (despite the name?) I did the same thing with an explanatory note about my pile of build changes, and I suppose that also went to /dev/null. Here's my last message, have had no response. I'm happy with anything that allows this relatively obscure platform to get through the build (this is the old Metrowerks + PowerPC BeOS platform, which is kind of a thing of the past since no supported hardware has been made for years.) The suggested variations on the patch are workable, so it's fine with me, but of course the patch as I sent it was also fine from my point of view. Donn Cave, University Computing Services, University of Washington donn@u.washington.edu ----------------------------- Date: Wed, 4 Oct 2000 17:08:52 -0700 (PDT) From: Donn Cave To: patches@python.org Subject: Re: [Patches] Re: [Patch #101773] BeOS PPC lacks fseeko, but isn't MS Windows In-Reply-To: <20001004134610.D1657@ActiveState.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII | Yes, again, you are right that that would be complex. If _fseek is equivalent | to fseeko then it should follow the same path through the code as fseeko. | Maybe then #define a FSEEKO, something like | | #ifdef __BEOS__ | /* can this be made to specify the BeOS PPC branch specifically? */ | #define FSEEKO _fseek | #else | #define FSEEKO fseeko | #endif | | Would you be able to try that? It will work. The platform would be #if defined(__BEOS__) && defined(__MWERKS__) (use _fseek()) If you like, you can even use fseeko: #if !defined(HAVE_FSEEKO) && defined(__BEOS__) # define fseeko _fseek # define HAVE_FSEEKO 1 #endif Incidentally, after some tests, I am more inclined to think BeOS does support these functions in a meaningful way. We don't have "holes", so I can't write at 64 bit locations in any file, but I do get "No space left on device", and I take that as evidence that they're not just ignoring the high bits of the parameter. Donn Cave, donn@oz.net From fdrake@beopen.com Fri Oct 6 18:41:09 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Fri, 6 Oct 2000 13:41:09 -0400 (EDT) Subject: [Patches] Re: [Patch #101773] BeOS PPC lacks fseeko, but isn't MS Windows In-Reply-To: <200010061731.KAA00952@mailhost1.u.washington.edu> References: <200010061731.KAA00952@mailhost1.u.washington.edu> Message-ID: <14814.3765.331684.480358@cj42289-a.reston1.va.home.com> Donn Cave writes: > I have actually corresponded with him on this one. I sent the > mail to patches@python.org, and omitted noreply@sourceforge.net. > He was getting them, but they didn't show up in the followups, > should I have been sending to noreply (despite the name?) I did Mail regarding bugs is not attached to the bugs in any way (unfortunately); the SourceForge crew doesn't seem to want to add this. ;( The best way to comment on a bug is through the SF interface. > Here's my last message, have had no response. I'm happy with anything > that allows this relatively obscure platform to get through the build > (this is the old Metrowerks + PowerPC BeOS platform, which is kind of > a thing of the past since no supported hardware has been made for years.) Hmm... and it's running BeOS R5? Or are these patches separate from the R5 patches? If you could paste your mail into SourceForge for the comments, I'd really appreciate it! Thanks for getting back to me so quickly! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From noreply@sourceforge.net Fri Oct 6 19:04:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 6 Oct 2000 11:04:19 -0700 Subject: [Patches] [Patch #101773] BeOS PPC lacks fseeko, but isn't MS Windows Message-ID: <200010061804.LAA28623@bush.i.sourceforge.net> Patch #101773 has been updated. Project: Category: Build Status: Open Summary: BeOS PPC lacks fseeko, but isn't MS Windows Follow-Ups: Date: 2000-Oct-04 11:18 By: tmick Comment: This is similar to a recent NetBSD 1.4.2 problem (cf: http://sourceforge.net/bugs/?func=detailbug&bug_id=112289&group_id=5470) The problem: NetBSD 1.4.2 and now I think BeOS pass the configure test for HAVE_LARGEFILE_SUPPORT but neither defines either fseeko() or fseek64() as required by the Single Unix Specification. That sucks. Question: What is this _fseek() in youy patch? This is a BeOS specific thing (sigh) I presume? Does it support large files, or pretend to? You can tell by the type of the second argument (the offset). If it is 'off_t' then it presumes to support largefiles. If it is 'long' then it does not. How is _fseek() different from fseek() on BeOS? Right Answer (tm): If this _fseek() does *not* support largefiles then I *think* the right answer is to change the HAVE_LARGEFILE_SUUPORT test such that it is *false* for NetBSD 1.4.2 and BeOS. I don't have the time (or a box to test this on) to try to get the right answer, though. So fat lot of good this comment is. It might be preferable to copy the NetBSD/OpenBSD patch (search NetBSD in the same file). Add __BEOS__. Does that work then? ------------------------------------------------------- Date: 2000-Oct-06 09:22 By: fdrake Comment: I've asked Donn to respond to Trent's comments; waiting for a response before taking further action on this patch. ------------------------------------------------------- Date: 2000-Oct-06 11:04 By: donnc Comment: Dang, I seem to have missed this wonderful SF gimmick by answering my email correspondence by email. Here is the last message I sent to tmick: Date: Wed, 4 Oct 2000 17:08:52 -0700 (PDT) From: Donn Cave To: patches@python.org Subject: Re: [Patches] Re: [Patch #101773] BeOS PPC lacks fseeko, but isn't MS Windows In-Reply-To: <20001004134610.D1657@ActiveState.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII | Yes, again, you are right that that would be complex. If _fseek is equivalent | to fseeko then it should follow the same path through the code as fseeko. | Maybe then #define a FSEEKO, something like | | #ifdef __BEOS__ | /* can this be made to specify the BeOS PPC branch specifically? */ | #define FSEEKO _fseek | #else | #define FSEEKO fseeko | #endif | | Would you be able to try that? It will work. The platform would be #if defined(__BEOS__) && defined(__MWERKS__) (use _fseek()) If you like, you can even use fseeko: #if !defined(HAVE_FSEEKO) && defined(__BEOS__) # define fseeko _fseek # define HAVE_FSEEKO 1 #endif Incidentally, after some tests, I am more inclined to think BeOS does support these functions in a meaningful way. We don't have "holes", so I can't write at 64 bit locations in any file, but I do get "No space left on device", and I take that as evidence that they're not just ignoring the high bits of the parameter. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101773&group_id=5470 From noreply@sourceforge.net Fri Oct 6 19:04:20 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 6 Oct 2000 11:04:20 -0700 Subject: [Patches] [Patch #101773] BeOS PPC lacks fseeko, but isn't MS Windows Message-ID: <200010061804.LAA28627@bush.i.sourceforge.net> Patch #101773 has been updated. Project: Category: Build Status: Open Summary: BeOS PPC lacks fseeko, but isn't MS Windows Follow-Ups: Date: 2000-Oct-04 11:18 By: tmick Comment: This is similar to a recent NetBSD 1.4.2 problem (cf: http://sourceforge.net/bugs/?func=detailbug&bug_id=112289&group_id=5470) The problem: NetBSD 1.4.2 and now I think BeOS pass the configure test for HAVE_LARGEFILE_SUPPORT but neither defines either fseeko() or fseek64() as required by the Single Unix Specification. That sucks. Question: What is this _fseek() in youy patch? This is a BeOS specific thing (sigh) I presume? Does it support large files, or pretend to? You can tell by the type of the second argument (the offset). If it is 'off_t' then it presumes to support largefiles. If it is 'long' then it does not. How is _fseek() different from fseek() on BeOS? Right Answer (tm): If this _fseek() does *not* support largefiles then I *think* the right answer is to change the HAVE_LARGEFILE_SUUPORT test such that it is *false* for NetBSD 1.4.2 and BeOS. I don't have the time (or a box to test this on) to try to get the right answer, though. So fat lot of good this comment is. It might be preferable to copy the NetBSD/OpenBSD patch (search NetBSD in the same file). Add __BEOS__. Does that work then? ------------------------------------------------------- Date: 2000-Oct-06 09:22 By: fdrake Comment: I've asked Donn to respond to Trent's comments; waiting for a response before taking further action on this patch. ------------------------------------------------------- Date: 2000-Oct-06 11:04 By: donnc Comment: Dang, I seem to have missed this wonderful SF gimmick by answering my email correspondence by email. Here is the last message I sent to tmick: Date: Wed, 4 Oct 2000 17:08:52 -0700 (PDT) From: Donn Cave To: patches@python.org Subject: Re: [Patches] Re: [Patch #101773] BeOS PPC lacks fseeko, but isn't MS Windows In-Reply-To: <20001004134610.D1657@ActiveState.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII | Yes, again, you are right that that would be complex. If _fseek is equivalent | to fseeko then it should follow the same path through the code as fseeko. | Maybe then #define a FSEEKO, something like | | #ifdef __BEOS__ | /* can this be made to specify the BeOS PPC branch specifically? */ | #define FSEEKO _fseek | #else | #define FSEEKO fseeko | #endif | | Would you be able to try that? It will work. The platform would be #if defined(__BEOS__) && defined(__MWERKS__) (use _fseek()) If you like, you can even use fseeko: #if !defined(HAVE_FSEEKO) && defined(__BEOS__) # define fseeko _fseek # define HAVE_FSEEKO 1 #endif Incidentally, after some tests, I am more inclined to think BeOS does support these functions in a meaningful way. We don't have "holes", so I can't write at 64 bit locations in any file, but I do get "No space left on device", and I take that as evidence that they're not just ignoring the high bits of the parameter. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101773&group_id=5470 From donn@u.washington.edu Fri Oct 6 19:24:01 2000 From: donn@u.washington.edu (Donn Cave) Date: Fri, 6 Oct 2000 11:24:01 -0700 Subject: [Patches] Re: [Patch #101773] BeOS PPC lacks fseeko, but isn't MS Windows Message-ID: <200010061824.LAA10501@mailhost1.u.washington.edu> | Mail regarding bugs is not attached to the bugs in any way | (unfortunately); the SourceForge crew doesn't seem to want to add | this. ;( The best way to comment on a bug is through the SF | interface. Bleah. |> Here's my last message, have had no response. I'm happy with anything |> that allows this relatively obscure platform to get through the build |> (this is the old Metrowerks + PowerPC BeOS platform, which is kind of |> a thing of the past since no supported hardware has been made for years.) | | Hmm... and it's running BeOS R5? Or are these patches separate from | the R5 patches? | If you could paste your mail into SourceForge for the comments, I'd | really appreciate it! OK, pasted. Be has continued to support the platform for a limited time as a legacy, so R5 works. Actually I don't believe there's a single thing in the patches I sent in Wednesday that has to do with R5, we have the same issues on R4.5.2. Most of the hassle is the Metrowerks compiler tools, on the PPC platform but with some legacy there in how Be handles the Intel platform too, and anyway some spillover of the PPC issues into the Python build and install on Intel. It hadn't been (Python 1.5) building on PPC, and it hadn't been installing correctly on Intel either (dl_export.h in the wrong directory, it should be in the includes) ... despite all the junk in configure to support it. The "revise BeOS build" patches, need to be taken (or rejected) together, or revised. The rest can be taken separately. Donn Cave, donn@u.washington.edu From noreply@sourceforge.net Fri Oct 6 19:25:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 6 Oct 2000 11:25:25 -0700 Subject: [Patches] [Patch #101807] Patch for SRE character class bug (#116251) Message-ID: <200010061825.LAA29487@bush.i.sourceforge.net> Patch #101807 has been updated. Project: Category: library Status: Open Summary: Patch for SRE character class bug (#116251) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101807&group_id=5470 From noreply@sourceforge.net Fri Oct 6 19:25:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 6 Oct 2000 11:25:53 -0700 Subject: [Patches] [Patch #101807] Patch for SRE character class bug (#116251) Message-ID: <200010061825.LAA29504@bush.i.sourceforge.net> Patch #101807 has been updated. Project: Category: library Status: Open Summary: Patch for SRE character class bug (#116251) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101807&group_id=5470 From noreply@sourceforge.net Fri Oct 6 19:47:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 6 Oct 2000 11:47:13 -0700 Subject: [Patches] [Patch #101709] test_import to verify that .pyc files can be imported Message-ID: <200010061847.LAA21506@delerium.i.sourceforge.net> Patch #101709 has been updated. Project: Category: core (C code) Status: Closed Summary: test_import to verify that .pyc files can be imported Follow-Ups: Date: 2000-Sep-29 07:38 By: jhylton Comment: Will this detect the error in 2.0b2 and run on Windows? ------------------------------------------------------- Date: 2000-Oct-06 09:56 By: tim_one Comment: Accepted and assigned back to Jeremy, but unsure of which "error in 2.0b2" you're talking about. The Windows-specific magic number screwup? If so, yes: C:\Python20>python /code/python/dist/src/lib/test/test_import.py Traceback (most recent call last): File "/code/python/dist/src/lib/test/test_import.py", line 35, in ? raise ValueError, "import from .pyc/.pyo failed: %s" % err ValueError: import from .pyc/.pyo failed: Bad magic number in @test.pyc C:\Python20> One style nit: print >> f, "a = %s" % a print >> f, "b = %s" % b would be clearer as: print >> f, "a =", a print >> f, "b =", b ------------------------------------------------------- Date: 2000-Oct-06 11:47 By: tim_one Comment: Closed. I added this (and a test/output/test_import file) after making the style change noted earlier. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101709&group_id=5470 From noreply@sourceforge.net Fri Oct 6 20:51:26 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 6 Oct 2000 12:51:26 -0700 Subject: [Patches] [Patch #101810] Fix MemoryError when decompressing empty string Message-ID: <200010061951.MAA00525@bush.i.sourceforge.net> Patch #101810 has been updated. Project: Category: Modules Status: Open Summary: Fix MemoryError when decompressing empty string ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101810&group_id=5470 From noreply@sourceforge.net Fri Oct 6 20:51:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 6 Oct 2000 12:51:59 -0700 Subject: [Patches] [Patch #101810] Fix MemoryError when decompressing empty string Message-ID: <200010061951.MAA00539@bush.i.sourceforge.net> Patch #101810 has been updated. Project: Category: Modules Status: Open Summary: Fix MemoryError when decompressing empty string ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101810&group_id=5470 From noreply@sourceforge.net Fri Oct 6 21:07:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 6 Oct 2000 13:07:55 -0700 Subject: [Patches] [Patch #101810] Fix MemoryError when decompressing empty string Message-ID: <200010062007.NAA01110@bush.i.sourceforge.net> Patch #101810 has been updated. Project: Category: Modules Status: Accepted Summary: Fix MemoryError when decompressing empty string Follow-Ups: Date: 2000-Oct-06 13:07 By: jhylton Comment: Change this: if (0 < zst.avail_out) to this: if (zst.avail_out > 0) and it's fine. Do you want to check it in or should I? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101810&group_id=5470 From noreply@sourceforge.net Fri Oct 6 21:15:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 6 Oct 2000 13:15:45 -0700 Subject: [Patches] [Patch #101810] Fix MemoryError when decompressing empty string Message-ID: <200010062015.NAA25117@delerium.i.sourceforge.net> Patch #101810 has been updated. Project: Category: Modules Status: Accepted Summary: Fix MemoryError when decompressing empty string Follow-Ups: Date: 2000-Oct-06 13:07 By: jhylton Comment: Change this: if (0 < zst.avail_out) to this: if (zst.avail_out > 0) and it's fine. Do you want to check it in or should I? ------------------------------------------------------- Date: 2000-Oct-06 13:15 By: akuchling Comment: One final reservation: the zlib library's API is poorly defined. As I interpret the docs quoted in the DejaNews posting, this change is correct. It might break with old versions of the zlib library. On the other hand, the current version has been 1.1.3 since 1998. I'd suggest checking in the patch, but if you want to be conservative, let me know. If I get a go-ahead in the next hour or so, I'll be around to check it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101810&group_id=5470 From noreply@sourceforge.net Fri Oct 6 21:43:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 6 Oct 2000 13:43:10 -0700 Subject: [Patches] [Patch #101773] BeOS PPC lacks fseeko, but isn't MS Windows Message-ID: <200010062043.NAA02524@bush.i.sourceforge.net> Patch #101773 has been updated. Project: Category: Build Status: Closed Summary: BeOS PPC lacks fseeko, but isn't MS Windows Follow-Ups: Date: 2000-Oct-04 11:18 By: tmick Comment: This is similar to a recent NetBSD 1.4.2 problem (cf: http://sourceforge.net/bugs/?func=detailbug&bug_id=112289&group_id=5470) The problem: NetBSD 1.4.2 and now I think BeOS pass the configure test for HAVE_LARGEFILE_SUPPORT but neither defines either fseeko() or fseek64() as required by the Single Unix Specification. That sucks. Question: What is this _fseek() in youy patch? This is a BeOS specific thing (sigh) I presume? Does it support large files, or pretend to? You can tell by the type of the second argument (the offset). If it is 'off_t' then it presumes to support largefiles. If it is 'long' then it does not. How is _fseek() different from fseek() on BeOS? Right Answer (tm): If this _fseek() does *not* support largefiles then I *think* the right answer is to change the HAVE_LARGEFILE_SUUPORT test such that it is *false* for NetBSD 1.4.2 and BeOS. I don't have the time (or a box to test this on) to try to get the right answer, though. So fat lot of good this comment is. It might be preferable to copy the NetBSD/OpenBSD patch (search NetBSD in the same file). Add __BEOS__. Does that work then? ------------------------------------------------------- Date: 2000-Oct-06 09:22 By: fdrake Comment: I've asked Donn to respond to Trent's comments; waiting for a response before taking further action on this patch. ------------------------------------------------------- Date: 2000-Oct-06 11:04 By: donnc Comment: Dang, I seem to have missed this wonderful SF gimmick by answering my email correspondence by email. Here is the last message I sent to tmick: Date: Wed, 4 Oct 2000 17:08:52 -0700 (PDT) From: Donn Cave To: patches@python.org Subject: Re: [Patches] Re: [Patch #101773] BeOS PPC lacks fseeko, but isn't MS Windows In-Reply-To: <20001004134610.D1657@ActiveState.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII | Yes, again, you are right that that would be complex. If _fseek is equivalent | to fseeko then it should follow the same path through the code as fseeko. | Maybe then #define a FSEEKO, something like | | #ifdef __BEOS__ | /* can this be made to specify the BeOS PPC branch specifically? */ | #define FSEEKO _fseek | #else | #define FSEEKO fseeko | #endif | | Would you be able to try that? It will work. The platform would be #if defined(__BEOS__) && defined(__MWERKS__) (use _fseek()) If you like, you can even use fseeko: #if !defined(HAVE_FSEEKO) && defined(__BEOS__) # define fseeko _fseek # define HAVE_FSEEKO 1 #endif Incidentally, after some tests, I am more inclined to think BeOS does support these functions in a meaningful way. We don't have "holes", so I can't write at 64 bit locations in any file, but I do get "No space left on device", and I take that as evidence that they're not just ignoring the high bits of the parameter. ------------------------------------------------------- Date: 2000-Oct-06 13:43 By: fdrake Comment: Since there appear to be multiple ways to fix this, so I'll take the patch that's already posted. Checked in as Objects/fileobject.c revision 2.90. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101773&group_id=5470 From noreply@sourceforge.net Fri Oct 6 21:57:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 6 Oct 2000 13:57:49 -0700 Subject: [Patches] [Patch #101721] Fix for 115530/1: add closed attribute to cStringIO objects Message-ID: <200010062057.NAA03088@bush.i.sourceforge.net> Patch #101721 has been updated. Project: Category: Modules Status: Closed Summary: Fix for 115530/1: add closed attribute to cStringIO objects Follow-Ups: Date: 2000-Sep-30 09:25 By: loewis Comment: I have updated the patch to also fix 115530. The only remaining difference to StringIO is that cStringIO.readline does not support a maxsize argument. To add this parameter, the C API of cStringIO must be changed, and in turn cPickle. Is such a correction desirable? ------------------------------------------------------- Date: 2000-Sep-30 17:10 By: fdrake Comment: Assigned to Ken to pass along to Jim Fulton -- please mark this "Accepted" and assign to Martin to approve this for checkin, or update a revised patch. ------------------------------------------------------- Date: 2000-Oct-06 13:57 By: fdrake Comment: Bug was fixed by Jim's checkin of Modules/cStringIO.c revision 2.27. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101721&group_id=5470 From noreply@sourceforge.net Sat Oct 7 04:37:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 6 Oct 2000 20:37:34 -0700 Subject: [Patches] [Patch #101816] Fixes shared modules on Mac OS X Message-ID: <200010070337.UAA08884@delerium.i.sourceforge.net> Patch #101816 has been updated. Project: Category: None Status: Open Summary: Fixes shared modules on Mac OS X ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101816&group_id=5470 From noreply@sourceforge.net Sat Oct 7 04:47:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 6 Oct 2000 20:47:44 -0700 Subject: [Patches] [Patch #101816] Fixes shared modules on Mac OS X Message-ID: <200010070347.UAA17648@bush.i.sourceforge.net> Patch #101816 has been updated. Project: Category: None Status: Open Summary: Fixes shared modules on Mac OS X Follow-Ups: Date: 2000-Oct-06 20:47 By: tonylownds Comment: Martin v. Loewis suggested I post this patch; it changes configure.in and configure: 1. Mac OS X is recognized by the Next-ish host recognition code as "darwin/1.2" 2. When specifying just --with-dyld, modules can compile as shared 3. --with-dyld and --with-next-framework, modules can compile as shared 4. --with-suffix=.exe, and Lib/plat-darwin1.2 is being made, the regen script invokes python as python.exe ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101816&group_id=5470 From noreply@sourceforge.net Sat Oct 7 04:47:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 6 Oct 2000 20:47:45 -0700 Subject: [Patches] [Patch #101816] Fixes shared modules on Mac OS X Message-ID: <200010070347.UAA17651@bush.i.sourceforge.net> Patch #101816 has been updated. Project: Category: None Status: Open Summary: Fixes shared modules on Mac OS X Follow-Ups: Date: 2000-Oct-06 20:47 By: tonylownds Comment: Martin v. Loewis suggested I post this patch; it changes configure.in and configure: 1. Mac OS X is recognized by the Next-ish host recognition code as "darwin/1.2" 2. When specifying just --with-dyld, modules can compile as shared 3. --with-dyld and --with-next-framework, modules can compile as shared 4. --with-suffix=.exe, and Lib/plat-darwin1.2 is being made, the regen script invokes python as python.exe ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101816&group_id=5470 From noreply@sourceforge.net Sat Oct 7 04:54:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 6 Oct 2000 20:54:37 -0700 Subject: [Patches] [Patch #101816] Fixes shared modules on Mac OS X Message-ID: <200010070354.UAA09457@delerium.i.sourceforge.net> Patch #101816 has been updated. Project: Category: None Status: Open Summary: Fixes shared modules on Mac OS X Follow-Ups: Date: 2000-Oct-06 20:47 By: tonylownds Comment: Martin v. Loewis suggested I post this patch; it changes configure.in and configure: 1. Mac OS X is recognized by the Next-ish host recognition code as "darwin/1.2" 2. When specifying just --with-dyld, modules can compile as shared 3. --with-dyld and --with-next-framework, modules can compile as shared 4. --with-suffix=.exe, and Lib/plat-darwin1.2 is being made, the regen script invokes python as python.exe ------------------------------------------------------- Date: 2000-Oct-06 20:54 By: tonylownds Comment: New version does not patch configure, as this was 160 needless kb. New version is 4181 bytes. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101816&group_id=5470 From noreply@sourceforge.net Sat Oct 7 04:54:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 6 Oct 2000 20:54:37 -0700 Subject: [Patches] [Patch #101816] Fixes shared modules on Mac OS X Message-ID: <200010070354.UAA09454@delerium.i.sourceforge.net> Patch #101816 has been updated. Project: Category: None Status: Open Summary: Fixes shared modules on Mac OS X Follow-Ups: Date: 2000-Oct-06 20:47 By: tonylownds Comment: Martin v. Loewis suggested I post this patch; it changes configure.in and configure: 1. Mac OS X is recognized by the Next-ish host recognition code as "darwin/1.2" 2. When specifying just --with-dyld, modules can compile as shared 3. --with-dyld and --with-next-framework, modules can compile as shared 4. --with-suffix=.exe, and Lib/plat-darwin1.2 is being made, the regen script invokes python as python.exe ------------------------------------------------------- Date: 2000-Oct-06 20:54 By: tonylownds Comment: New version does not patch configure, as this was 160 needless kb. New version is 4181 bytes. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101816&group_id=5470 From noreply@sourceforge.net Sat Oct 7 11:00:30 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 7 Oct 2000 03:00:30 -0700 Subject: [Patches] [Patch #101807] Patch for SRE character class bug (#116251) Message-ID: <200010071000.DAA20896@delerium.i.sourceforge.net> Patch #101807 has been updated. Project: Category: library Status: Accepted Summary: Patch for SRE character class bug (#116251) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101807&group_id=5470 From noreply@sourceforge.net Sat Oct 7 12:14:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 7 Oct 2000 04:14:00 -0700 Subject: [Patches] [Patch #101801] Prevent possible buffer exploits under Windows Message-ID: <200010071114.EAA23283@delerium.i.sourceforge.net> Patch #101801 has been updated. Project: Category: Windows Status: Closed Summary: Prevent possible buffer exploits under Windows Follow-Ups: Date: 2000-Oct-05 20:46 By: mhammond Comment: Assigning to myself - will ask for review on python-dev, then checkin before RC release. ------------------------------------------------------- Date: 2000-Oct-07 04:13 By: mhammond Comment: Checked in as Rev 1.22 of getpathp.c ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101801&group_id=5470 From noreply@sourceforge.net Sat Oct 7 12:31:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 7 Oct 2000 04:31:59 -0700 Subject: [Patches] [Patch #101801] Prevent possible buffer exploits under Windows Message-ID: <200010071131.EAA23894@delerium.i.sourceforge.net> Patch #101801 has been updated. Project: Category: Windows Status: Closed Summary: Prevent possible buffer exploits under Windows Follow-Ups: Date: 2000-Oct-05 20:46 By: mhammond Comment: Assigning to myself - will ask for review on python-dev, then checkin before RC release. ------------------------------------------------------- Date: 2000-Oct-07 04:13 By: mhammond Comment: Checked in as Rev 1.22 of getpathp.c ------------------------------------------------------- Date: 2000-Oct-07 04:31 By: mhammond Comment: Checked in as Rev 1.22 of getpathp.c ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101801&group_id=5470 From noreply@sourceforge.net Sat Oct 7 13:06:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 7 Oct 2000 05:06:52 -0700 Subject: [Patches] [Patch #101821] xmldomminidom.tex: Documentation for minidom Message-ID: <200010071206.FAA01244@bush.i.sourceforge.net> Patch #101821 has been updated. Project: Category: documentation Status: Open Summary: xmldomminidom.tex: Documentation for minidom ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101821&group_id=5470 From noreply@sourceforge.net Sat Oct 7 16:23:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 7 Oct 2000 08:23:01 -0700 Subject: [Patches] [Patch #101816] Fixes shared modules on Mac OS X Message-ID: <200010071523.IAA31531@delerium.i.sourceforge.net> Patch #101816 has been updated. Project: Category: None Status: Open Summary: Fixes shared modules on Mac OS X Follow-Ups: Date: 2000-Oct-06 20:47 By: tonylownds Comment: Martin v. Loewis suggested I post this patch; it changes configure.in and configure: 1. Mac OS X is recognized by the Next-ish host recognition code as "darwin/1.2" 2. When specifying just --with-dyld, modules can compile as shared 3. --with-dyld and --with-next-framework, modules can compile as shared 4. --with-suffix=.exe, and Lib/plat-darwin1.2 is being made, the regen script invokes python as python.exe ------------------------------------------------------- Date: 2000-Oct-06 20:54 By: tonylownds Comment: New version does not patch configure, as this was 160 needless kb. New version is 4181 bytes. ------------------------------------------------------- Date: 2000-Oct-07 08:23 By: none Comment: 1) some of the fixes have previously been checked in. 2) uname of release is Darwin not darwin 3) it looks as if this patch is corrupted ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101816&group_id=5470 From noreply@sourceforge.net Sat Oct 7 16:23:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 7 Oct 2000 08:23:01 -0700 Subject: [Patches] [Patch #101816] Fixes shared modules on Mac OS X Message-ID: <200010071523.IAA31528@delerium.i.sourceforge.net> Patch #101816 has been updated. Project: Category: None Status: Open Summary: Fixes shared modules on Mac OS X Follow-Ups: Date: 2000-Oct-06 20:47 By: tonylownds Comment: Martin v. Loewis suggested I post this patch; it changes configure.in and configure: 1. Mac OS X is recognized by the Next-ish host recognition code as "darwin/1.2" 2. When specifying just --with-dyld, modules can compile as shared 3. --with-dyld and --with-next-framework, modules can compile as shared 4. --with-suffix=.exe, and Lib/plat-darwin1.2 is being made, the regen script invokes python as python.exe ------------------------------------------------------- Date: 2000-Oct-06 20:54 By: tonylownds Comment: New version does not patch configure, as this was 160 needless kb. New version is 4181 bytes. ------------------------------------------------------- Date: 2000-Oct-07 08:23 By: none Comment: 1) some of the fixes have previously been checked in. 2) uname of release is Darwin not darwin 3) it looks as if this patch is corrupted ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101816&group_id=5470 From noreply@sourceforge.net Sat Oct 7 19:07:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 7 Oct 2000 11:07:15 -0700 Subject: [Patches] [Patch #101816] Fixes shared modules on Mac OS X Message-ID: <200010071807.LAA12988@bush.i.sourceforge.net> Patch #101816 has been updated. Project: Category: None Status: Open Summary: Fixes shared modules on Mac OS X Follow-Ups: Date: 2000-Oct-06 20:47 By: tonylownds Comment: Martin v. Loewis suggested I post this patch; it changes configure.in and configure: 1. Mac OS X is recognized by the Next-ish host recognition code as "darwin/1.2" 2. When specifying just --with-dyld, modules can compile as shared 3. --with-dyld and --with-next-framework, modules can compile as shared 4. --with-suffix=.exe, and Lib/plat-darwin1.2 is being made, the regen script invokes python as python.exe ------------------------------------------------------- Date: 2000-Oct-06 20:54 By: tonylownds Comment: New version does not patch configure, as this was 160 needless kb. New version is 4181 bytes. ------------------------------------------------------- Date: 2000-Oct-07 08:23 By: none Comment: 1) some of the fixes have previously been checked in. 2) uname of release is Darwin not darwin 3) it looks as if this patch is corrupted ------------------------------------------------------- Date: 2000-Oct-07 11:07 By: none Comment: 1) some of the fixes have previously been checked in. 2) uname of release is Darwin not darwin 3) it looks as if this patch is corrupted ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101816&group_id=5470 From noreply@sourceforge.net Sat Oct 7 19:07:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 7 Oct 2000 11:07:16 -0700 Subject: [Patches] [Patch #101816] Fixes shared modules on Mac OS X Message-ID: <200010071807.LAA12991@bush.i.sourceforge.net> Patch #101816 has been updated. Project: Category: None Status: Open Summary: Fixes shared modules on Mac OS X Follow-Ups: Date: 2000-Oct-06 20:47 By: tonylownds Comment: Martin v. Loewis suggested I post this patch; it changes configure.in and configure: 1. Mac OS X is recognized by the Next-ish host recognition code as "darwin/1.2" 2. When specifying just --with-dyld, modules can compile as shared 3. --with-dyld and --with-next-framework, modules can compile as shared 4. --with-suffix=.exe, and Lib/plat-darwin1.2 is being made, the regen script invokes python as python.exe ------------------------------------------------------- Date: 2000-Oct-06 20:54 By: tonylownds Comment: New version does not patch configure, as this was 160 needless kb. New version is 4181 bytes. ------------------------------------------------------- Date: 2000-Oct-07 08:23 By: none Comment: 1) some of the fixes have previously been checked in. 2) uname of release is Darwin not darwin 3) it looks as if this patch is corrupted ------------------------------------------------------- Date: 2000-Oct-07 11:07 By: none Comment: 1) some of the fixes have previously been checked in. 2) uname of release is Darwin not darwin 3) it looks as if this patch is corrupted ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101816&group_id=5470 From noreply@sourceforge.net Sat Oct 7 19:38:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 7 Oct 2000 11:38:18 -0700 Subject: [Patches] [Patch #101823] Fix Darwin POSIX Thread redefinition Message-ID: <200010071838.LAA06220@delerium.i.sourceforge.net> Patch #101823 has been updated. Project: Category: None Status: Open Summary: Fix Darwin POSIX Thread redefinition ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101823&group_id=5470 From noreply@sourceforge.net Sat Oct 7 19:40:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 7 Oct 2000 11:40:38 -0700 Subject: [Patches] [Patch #101823] Fix Darwin POSIX Thread redefinition Message-ID: <200010071840.LAA06261@delerium.i.sourceforge.net> Patch #101823 has been updated. Project: Category: None Status: Open Summary: Fix Darwin POSIX Thread redefinition Follow-Ups: Date: 2000-Oct-07 11:40 By: dkwolfe Comment: Oh, one other thing. The patch does not include the changes to configure - you'll need to run autoconf to make those changes. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101823&group_id=5470 From noreply@sourceforge.net Sat Oct 7 19:40:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 7 Oct 2000 11:40:36 -0700 Subject: [Patches] [Patch #101823] Fix Darwin POSIX Thread redefinition Message-ID: <200010071840.LAA06258@delerium.i.sourceforge.net> Patch #101823 has been updated. Project: Category: None Status: Open Summary: Fix Darwin POSIX Thread redefinition Follow-Ups: Date: 2000-Oct-07 11:40 By: dkwolfe Comment: Oh, one other thing. The patch does not include the changes to configure - you'll need to run autoconf to make those changes. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101823&group_id=5470 From noreply@sourceforge.net Sat Oct 7 20:08:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 7 Oct 2000 12:08:12 -0700 Subject: [Patches] [Patch #101824] On Darwin, remove unrecognized option `-OPT:Olimit=0' Message-ID: <200010071908.MAA15082@bush.i.sourceforge.net> Patch #101824 has been updated. Project: Category: None Status: Open Summary: On Darwin, remove unrecognized option `-OPT:Olimit=0' ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101824&group_id=5470 From noreply@sourceforge.net Sun Oct 8 04:00:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 7 Oct 2000 20:00:47 -0700 Subject: [Patches] [Patch #101821] xmldomminidom.tex: Documentation for minidom Message-ID: <200010080300.UAA24020@delerium.i.sourceforge.net> Patch #101821 has been updated. Project: Category: documentation Status: Open Summary: xmldomminidom.tex: Documentation for minidom ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101821&group_id=5470 From noreply@sourceforge.net Mon Oct 9 00:31:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 8 Oct 2000 16:31:03 -0700 Subject: [Patches] [Patch #101816] Fixes shared modules on Mac OS X Message-ID: <200010082331.QAA03440@delerium.i.sourceforge.net> Patch #101816 has been updated. Project: Category: None Status: Open Summary: Fixes shared modules on Mac OS X Follow-Ups: Date: 2000-Oct-06 20:47 By: tonylownds Comment: Martin v. Loewis suggested I post this patch; it changes configure.in and configure: 1. Mac OS X is recognized by the Next-ish host recognition code as "darwin/1.2" 2. When specifying just --with-dyld, modules can compile as shared 3. --with-dyld and --with-next-framework, modules can compile as shared 4. --with-suffix=.exe, and Lib/plat-darwin1.2 is being made, the regen script invokes python as python.exe ------------------------------------------------------- Date: 2000-Oct-06 20:54 By: tonylownds Comment: New version does not patch configure, as this was 160 needless kb. New version is 4181 bytes. ------------------------------------------------------- Date: 2000-Oct-07 08:23 By: none Comment: 1) some of the fixes have previously been checked in. 2) uname of release is Darwin not darwin 3) it looks as if this patch is corrupted ------------------------------------------------------- Date: 2000-Oct-07 11:07 By: none Comment: 1) some of the fixes have previously been checked in. 2) uname of release is Darwin not darwin 3) it looks as if this patch is corrupted ------------------------------------------------------- Date: 2000-Oct-08 16:31 By: none Comment: Redid patch against an up-to-date CVS tree ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101816&group_id=5470 From noreply@sourceforge.net Mon Oct 9 00:33:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 8 Oct 2000 16:33:56 -0700 Subject: [Patches] [Patch #101816] Fixes shared modules on Mac OS X Message-ID: <200010082333.QAA03618@delerium.i.sourceforge.net> Patch #101816 has been updated. Project: Category: None Status: Open Summary: Fixes shared modules on Mac OS X Follow-Ups: Date: 2000-Oct-06 20:47 By: tonylownds Comment: Martin v. Loewis suggested I post this patch; it changes configure.in and configure: 1. Mac OS X is recognized by the Next-ish host recognition code as "darwin/1.2" 2. When specifying just --with-dyld, modules can compile as shared 3. --with-dyld and --with-next-framework, modules can compile as shared 4. --with-suffix=.exe, and Lib/plat-darwin1.2 is being made, the regen script invokes python as python.exe ------------------------------------------------------- Date: 2000-Oct-06 20:54 By: tonylownds Comment: New version does not patch configure, as this was 160 needless kb. New version is 4181 bytes. ------------------------------------------------------- Date: 2000-Oct-07 08:23 By: none Comment: 1) some of the fixes have previously been checked in. 2) uname of release is Darwin not darwin 3) it looks as if this patch is corrupted ------------------------------------------------------- Date: 2000-Oct-07 11:07 By: none Comment: 1) some of the fixes have previously been checked in. 2) uname of release is Darwin not darwin 3) it looks as if this patch is corrupted ------------------------------------------------------- Date: 2000-Oct-08 16:31 By: none Comment: Redid patch against an up-to-date CVS tree ------------------------------------------------------- Date: 2000-Oct-08 16:33 By: tonylownds Comment: Re-did patch against an updated CVS checkout. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101816&group_id=5470 From noreply@sourceforge.net Mon Oct 9 00:33:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 8 Oct 2000 16:33:55 -0700 Subject: [Patches] [Patch #101816] Fixes shared modules on Mac OS X Message-ID: <200010082333.QAA03615@delerium.i.sourceforge.net> Patch #101816 has been updated. Project: Category: None Status: Open Summary: Fixes shared modules on Mac OS X Follow-Ups: Date: 2000-Oct-06 20:47 By: tonylownds Comment: Martin v. Loewis suggested I post this patch; it changes configure.in and configure: 1. Mac OS X is recognized by the Next-ish host recognition code as "darwin/1.2" 2. When specifying just --with-dyld, modules can compile as shared 3. --with-dyld and --with-next-framework, modules can compile as shared 4. --with-suffix=.exe, and Lib/plat-darwin1.2 is being made, the regen script invokes python as python.exe ------------------------------------------------------- Date: 2000-Oct-06 20:54 By: tonylownds Comment: New version does not patch configure, as this was 160 needless kb. New version is 4181 bytes. ------------------------------------------------------- Date: 2000-Oct-07 08:23 By: none Comment: 1) some of the fixes have previously been checked in. 2) uname of release is Darwin not darwin 3) it looks as if this patch is corrupted ------------------------------------------------------- Date: 2000-Oct-07 11:07 By: none Comment: 1) some of the fixes have previously been checked in. 2) uname of release is Darwin not darwin 3) it looks as if this patch is corrupted ------------------------------------------------------- Date: 2000-Oct-08 16:31 By: none Comment: Redid patch against an up-to-date CVS tree ------------------------------------------------------- Date: 2000-Oct-08 16:33 By: tonylownds Comment: Re-did patch against an updated CVS checkout. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101816&group_id=5470 From noreply@sourceforge.net Mon Oct 9 04:14:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 8 Oct 2000 20:14:23 -0700 Subject: [Patches] [Patch #101839] better error messages Message-ID: <200010090314.UAA18177@bush.i.sourceforge.net> Patch #101839 has been updated. Project: Category: core (C code) Status: Open Summary: better error messages ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101839&group_id=5470 From noreply@sourceforge.net Mon Oct 9 04:20:20 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 8 Oct 2000 20:20:20 -0700 Subject: [Patches] [Patch #101839] better error messages Message-ID: <200010090320.UAA18377@bush.i.sourceforge.net> Patch #101839 has been updated. Project: Category: core (C code) Status: Open Summary: better error messages Follow-Ups: Date: 2000-Oct-08 20:20 By: ping Comment: This patch tries to make the feedback from error messages more consistent and helpful. For example: >>> os.kf Traceback (most recent call last): File "", line 1, in ? AttributeError: 'os' module has no attribute 'kf' >>> int(a=3) Traceback (most recent call last): File "", line 1, in ? TypeError: int() takes no keyword arguments >>> class Foo: pass ... >>> Foo.spam Traceback (most recent call last): File "", line 1, in ? AttributeError: class Foo has no attribute 'spam' >>> Foo().spam Traceback (most recent call last): File "", line 1, in ? AttributeError: Foo instance has no attribute 'spam' >>> Foo()() Traceback (most recent call last): File "", line 1, in ? AttributeError: Foo instance has no __call__ method This isn't really a bug, but it's not a feature either. I wanted to get it in before the Monday freeze. If you have time, have a look; i'll leave it to your judgement whether it's okay to check in. I know it's close to the wire, but it's effectively small: there are no changes in logic, only strings edited here and there. The corresponding changes to the tests that relied on specific wording of error messages are also included. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101839&group_id=5470 From noreply@sourceforge.net Mon Oct 9 04:26:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 8 Oct 2000 20:26:31 -0700 Subject: [Patches] [Patch #101839] better error messages Message-ID: <200010090326.UAA18706@bush.i.sourceforge.net> Patch #101839 has been updated. Project: Category: core (C code) Status: Open Summary: better error messages Follow-Ups: Date: 2000-Oct-08 20:20 By: ping Comment: This patch tries to make the feedback from error messages more consistent and helpful. For example: >>> os.kf Traceback (most recent call last): File "", line 1, in ? AttributeError: 'os' module has no attribute 'kf' >>> int(a=3) Traceback (most recent call last): File "", line 1, in ? TypeError: int() takes no keyword arguments >>> class Foo: pass ... >>> Foo.spam Traceback (most recent call last): File "", line 1, in ? AttributeError: class Foo has no attribute 'spam' >>> Foo().spam Traceback (most recent call last): File "", line 1, in ? AttributeError: Foo instance has no attribute 'spam' >>> Foo()() Traceback (most recent call last): File "", line 1, in ? AttributeError: Foo instance has no __call__ method This isn't really a bug, but it's not a feature either. I wanted to get it in before the Monday freeze. If you have time, have a look; i'll leave it to your judgement whether it's okay to check in. I know it's close to the wire, but it's effectively small: there are no changes in logic, only strings edited here and there. The corresponding changes to the tests that relied on specific wording of error messages are also included. ------------------------------------------------------- Date: 2000-Oct-08 20:26 By: ping Comment: More examples: >>> import os >>> del os.kf Traceback (most recent call last): File "", line 1, in ? AttributeError: 'os' module has no attribute 'kf' >>> pow(3,4,0) Traceback (most recent call last): File "", line 1, in ? ValueError: pow() arg 3 cannot be 0 >>> os.execv('a', 3) Traceback (most recent call last): File "", line 1, in ? TypeError: execv() arg 2 must be a tuple or list >>> os.execv('a', (3,4)) Traceback (most recent call last): File "", line 1, in ? TypeError: execv() arg 2 must contain only strings >>> 0 ** -4 Traceback (most recent call last): File "", line 1, in ? ZeroDivisionError: cannot raise 0 to a negative power >>> int("45", 1) Traceback (most recent call last): File "", line 1, in ? ValueError: int() base must be >= 2 and <= 36 >>> ord(3) Traceback (most recent call last): File "", line 1, in ? TypeError: ord() expected string or Unicode character, int found ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101839&group_id=5470 From noreply@sourceforge.net Mon Oct 9 04:28:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 8 Oct 2000 20:28:43 -0700 Subject: [Patches] [Patch #101839] better error messages Message-ID: <200010090328.UAA18716@bush.i.sourceforge.net> Patch #101839 has been updated. Project: Category: core (C code) Status: Open Summary: better error messages Follow-Ups: Date: 2000-Oct-08 20:20 By: ping Comment: This patch tries to make the feedback from error messages more consistent and helpful. For example: >>> os.kf Traceback (most recent call last): File "", line 1, in ? AttributeError: 'os' module has no attribute 'kf' >>> int(a=3) Traceback (most recent call last): File "", line 1, in ? TypeError: int() takes no keyword arguments >>> class Foo: pass ... >>> Foo.spam Traceback (most recent call last): File "", line 1, in ? AttributeError: class Foo has no attribute 'spam' >>> Foo().spam Traceback (most recent call last): File "", line 1, in ? AttributeError: Foo instance has no attribute 'spam' >>> Foo()() Traceback (most recent call last): File "", line 1, in ? AttributeError: Foo instance has no __call__ method This isn't really a bug, but it's not a feature either. I wanted to get it in before the Monday freeze. If you have time, have a look; i'll leave it to your judgement whether it's okay to check in. I know it's close to the wire, but it's effectively small: there are no changes in logic, only strings edited here and there. The corresponding changes to the tests that relied on specific wording of error messages are also included. ------------------------------------------------------- Date: 2000-Oct-08 20:26 By: ping Comment: More examples: >>> import os >>> del os.kf Traceback (most recent call last): File "", line 1, in ? AttributeError: 'os' module has no attribute 'kf' >>> pow(3,4,0) Traceback (most recent call last): File "", line 1, in ? ValueError: pow() arg 3 cannot be 0 >>> os.execv('a', 3) Traceback (most recent call last): File "", line 1, in ? TypeError: execv() arg 2 must be a tuple or list >>> os.execv('a', (3,4)) Traceback (most recent call last): File "", line 1, in ? TypeError: execv() arg 2 must contain only strings >>> 0 ** -4 Traceback (most recent call last): File "", line 1, in ? ZeroDivisionError: cannot raise 0 to a negative power >>> int("45", 1) Traceback (most recent call last): File "", line 1, in ? ValueError: int() base must be >= 2 and <= 36 >>> ord(3) Traceback (most recent call last): File "", line 1, in ? TypeError: ord() expected string or Unicode character, int found ------------------------------------------------------- Date: 2000-Oct-08 20:28 By: ping Comment: Forgot to mention that this patch also includes changed names for audio formats in the linuxaudiodev module. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101839&group_id=5470 From noreply@sourceforge.net Mon Oct 9 05:10:14 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 8 Oct 2000 21:10:14 -0700 Subject: [Patches] [Patch #101779] revise BeOS build Message-ID: <200010090410.VAA20101@bush.i.sourceforge.net> Patch #101779 has been updated. Project: Category: Build Status: Closed Summary: revise BeOS build Follow-Ups: Date: 2000-Oct-06 09:17 By: fdrake Comment: Checked in as BeOS/README revision 1.10. ------------------------------------------------------- Date: 2000-Oct-08 21:10 By: donnc Comment: I'm sorry, if the rest of the patches in the "revise BeOS build" series (101774-101778) are out, then please reject this one also. Thanks, Donn ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101779&group_id=5470 From noreply@sourceforge.net Mon Oct 9 05:10:14 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 8 Oct 2000 21:10:14 -0700 Subject: [Patches] [Patch #101779] revise BeOS build Message-ID: <200010090410.VAA20104@bush.i.sourceforge.net> Patch #101779 has been updated. Project: Category: Build Status: Closed Summary: revise BeOS build Follow-Ups: Date: 2000-Oct-06 09:17 By: fdrake Comment: Checked in as BeOS/README revision 1.10. ------------------------------------------------------- Date: 2000-Oct-08 21:10 By: donnc Comment: I'm sorry, if the rest of the patches in the "revise BeOS build" series (101774-101778) are out, then please reject this one also. Thanks, Donn ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101779&group_id=5470 From noreply@sourceforge.net Mon Oct 9 09:05:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 01:05:29 -0700 Subject: [Patches] [Patch #101840] Minor fix in documentation of calendar module. Message-ID: <200010090805.BAA28187@bush.i.sourceforge.net> Patch #101840 has been updated. Project: Category: documentation Status: Open Summary: Minor fix in documentation of calendar module. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101840&group_id=5470 From noreply@sourceforge.net Mon Oct 9 09:13:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 01:13:02 -0700 Subject: [Patches] [Patch #101841] Minor fix in calendar module to work with "funny" years. Message-ID: <200010090813.BAA21963@delerium.i.sourceforge.net> Patch #101841 has been updated. Project: Category: library Status: Open Summary: Minor fix in calendar module to work with "funny" years. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101841&group_id=5470 From noreply@sourceforge.net Mon Oct 9 09:17:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 01:17:13 -0700 Subject: [Patches] [Patch #101841] Minor fix in calendar module to work with "funny" years. Message-ID: <200010090817.BAA22125@delerium.i.sourceforge.net> Patch #101841 has been updated. Project: Category: library Status: Open Summary: Minor fix in calendar module to work with "funny" years. Follow-Ups: Date: 2000-Oct-09 01:17 By: ods Comment: # Test suite that fails with unpatched version from calendar import * from random import randrange MIN_YEAR = 1600 MAX_YEAR = 2401 N_TRIES = 100 def test_leapdays(y1, y2): n_days = 0 for y in xrange(y1, y2): n_days += isleap(y) assert leapdays(y1, y2)==n_days for i in xrange(N_TRIES): y1 = randrange(MIN_YEAR, MAX_YEAR-1) y2 = randrange(y1+1, MAX_YEAR) test_leapdays(y1, y2) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101841&group_id=5470 From noreply@sourceforge.net Mon Oct 9 09:17:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 01:17:12 -0700 Subject: [Patches] [Patch #101841] Minor fix in calendar module to work with "funny" years. Message-ID: <200010090817.BAA22122@delerium.i.sourceforge.net> Patch #101841 has been updated. Project: Category: library Status: Open Summary: Minor fix in calendar module to work with "funny" years. Follow-Ups: Date: 2000-Oct-09 01:17 By: ods Comment: # Test suite that fails with unpatched version from calendar import * from random import randrange MIN_YEAR = 1600 MAX_YEAR = 2401 N_TRIES = 100 def test_leapdays(y1, y2): n_days = 0 for y in xrange(y1, y2): n_days += isleap(y) assert leapdays(y1, y2)==n_days for i in xrange(N_TRIES): y1 = randrange(MIN_YEAR, MAX_YEAR-1) y2 = randrange(y1+1, MAX_YEAR) test_leapdays(y1, y2) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101841&group_id=5470 From noreply@sourceforge.net Mon Oct 9 09:23:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 01:23:04 -0700 Subject: [Patches] [Patch #101842] Localization of calendar module. Message-ID: <200010090823.BAA22350@delerium.i.sourceforge.net> Patch #101842 has been updated. Project: Category: library Status: Open Summary: Localization of calendar module. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101842&group_id=5470 From noreply@sourceforge.net Mon Oct 9 09:34:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 01:34:02 -0700 Subject: [Patches] [Patch #101842] Localization of calendar module. Message-ID: <200010090834.BAA29321@bush.i.sourceforge.net> Patch #101842 has been updated. Project: Category: library Status: Open Summary: Localization of calendar module. Follow-Ups: Date: 2000-Oct-09 01:34 By: ods Comment: This work fine for all locales on NT, but may work a bit strange with some locales (e.g. ru_RU) on some platforms with buggy (IMHO) L10n of strftime (e.g. RedHat Linux). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101842&group_id=5470 From noreply@sourceforge.net Mon Oct 9 09:34:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 01:34:01 -0700 Subject: [Patches] [Patch #101842] Localization of calendar module. Message-ID: <200010090834.BAA29318@bush.i.sourceforge.net> Patch #101842 has been updated. Project: Category: library Status: Open Summary: Localization of calendar module. Follow-Ups: Date: 2000-Oct-09 01:34 By: ods Comment: This work fine for all locales on NT, but may work a bit strange with some locales (e.g. ru_RU) on some platforms with buggy (IMHO) L10n of strftime (e.g. RedHat Linux). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101842&group_id=5470 From noreply@sourceforge.net Mon Oct 9 13:32:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 05:32:11 -0700 Subject: [Patches] [Patch #101839] better error messages Message-ID: <200010091232.FAA06221@bush.i.sourceforge.net> Patch #101839 has been updated. Project: Category: core (C code) Status: Open Summary: better error messages Follow-Ups: Date: 2000-Oct-08 20:20 By: ping Comment: This patch tries to make the feedback from error messages more consistent and helpful. For example: >>> os.kf Traceback (most recent call last): File "", line 1, in ? AttributeError: 'os' module has no attribute 'kf' >>> int(a=3) Traceback (most recent call last): File "", line 1, in ? TypeError: int() takes no keyword arguments >>> class Foo: pass ... >>> Foo.spam Traceback (most recent call last): File "", line 1, in ? AttributeError: class Foo has no attribute 'spam' >>> Foo().spam Traceback (most recent call last): File "", line 1, in ? AttributeError: Foo instance has no attribute 'spam' >>> Foo()() Traceback (most recent call last): File "", line 1, in ? AttributeError: Foo instance has no __call__ method This isn't really a bug, but it's not a feature either. I wanted to get it in before the Monday freeze. If you have time, have a look; i'll leave it to your judgement whether it's okay to check in. I know it's close to the wire, but it's effectively small: there are no changes in logic, only strings edited here and there. The corresponding changes to the tests that relied on specific wording of error messages are also included. ------------------------------------------------------- Date: 2000-Oct-08 20:26 By: ping Comment: More examples: >>> import os >>> del os.kf Traceback (most recent call last): File "", line 1, in ? AttributeError: 'os' module has no attribute 'kf' >>> pow(3,4,0) Traceback (most recent call last): File "", line 1, in ? ValueError: pow() arg 3 cannot be 0 >>> os.execv('a', 3) Traceback (most recent call last): File "", line 1, in ? TypeError: execv() arg 2 must be a tuple or list >>> os.execv('a', (3,4)) Traceback (most recent call last): File "", line 1, in ? TypeError: execv() arg 2 must contain only strings >>> 0 ** -4 Traceback (most recent call last): File "", line 1, in ? ZeroDivisionError: cannot raise 0 to a negative power >>> int("45", 1) Traceback (most recent call last): File "", line 1, in ? ValueError: int() base must be >= 2 and <= 36 >>> ord(3) Traceback (most recent call last): File "", line 1, in ? TypeError: ord() expected string or Unicode character, int found ------------------------------------------------------- Date: 2000-Oct-08 20:28 By: ping Comment: Forgot to mention that this patch also includes changed names for audio formats in the linuxaudiodev module. ------------------------------------------------------- Date: 2000-Oct-09 05:32 By: gvanrossum Comment: Sorry, but this has to go in after 2.0 final is released. It's touching way too much code to be snuck in at the very last moment. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101839&group_id=5470 From noreply@sourceforge.net Mon Oct 9 13:42:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 05:42:16 -0700 Subject: [Patches] [Patch #101841] Minor fix in calendar module to work with "funny" years. Message-ID: <200010091242.FAA06615@bush.i.sourceforge.net> Patch #101841 has been updated. Project: Category: library Status: Closed Summary: Minor fix in calendar module to work with "funny" years. Follow-Ups: Date: 2000-Oct-09 01:17 By: ods Comment: # Test suite that fails with unpatched version from calendar import * from random import randrange MIN_YEAR = 1600 MAX_YEAR = 2401 N_TRIES = 100 def test_leapdays(y1, y2): n_days = 0 for y in xrange(y1, y2): n_days += isleap(y) assert leapdays(y1, y2)==n_days for i in xrange(N_TRIES): y1 = randrange(MIN_YEAR, MAX_YEAR-1) y2 = randrange(y1+1, MAX_YEAR) test_leapdays(y1, y2) ------------------------------------------------------- Date: 2000-Oct-09 05:42 By: gvanrossum Comment: Looks good. Thanks. Checked in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101841&group_id=5470 From noreply@sourceforge.net Mon Oct 9 13:44:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 05:44:46 -0700 Subject: [Patches] [Patch #101840] Minor fix in documentation of calendar module. Message-ID: <200010091244.FAA06677@bush.i.sourceforge.net> Patch #101840 has been updated. Project: Category: documentation Status: Open Summary: Minor fix in documentation of calendar module. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101840&group_id=5470 From noreply@sourceforge.net Mon Oct 9 13:46:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 05:46:19 -0700 Subject: [Patches] [Patch #101839] better error messages Message-ID: <200010091246.FAA06787@bush.i.sourceforge.net> Patch #101839 has been updated. Project: Category: core (C code) Status: Postponed Summary: better error messages Follow-Ups: Date: 2000-Oct-08 20:20 By: ping Comment: This patch tries to make the feedback from error messages more consistent and helpful. For example: >>> os.kf Traceback (most recent call last): File "", line 1, in ? AttributeError: 'os' module has no attribute 'kf' >>> int(a=3) Traceback (most recent call last): File "", line 1, in ? TypeError: int() takes no keyword arguments >>> class Foo: pass ... >>> Foo.spam Traceback (most recent call last): File "", line 1, in ? AttributeError: class Foo has no attribute 'spam' >>> Foo().spam Traceback (most recent call last): File "", line 1, in ? AttributeError: Foo instance has no attribute 'spam' >>> Foo()() Traceback (most recent call last): File "", line 1, in ? AttributeError: Foo instance has no __call__ method This isn't really a bug, but it's not a feature either. I wanted to get it in before the Monday freeze. If you have time, have a look; i'll leave it to your judgement whether it's okay to check in. I know it's close to the wire, but it's effectively small: there are no changes in logic, only strings edited here and there. The corresponding changes to the tests that relied on specific wording of error messages are also included. ------------------------------------------------------- Date: 2000-Oct-08 20:26 By: ping Comment: More examples: >>> import os >>> del os.kf Traceback (most recent call last): File "", line 1, in ? AttributeError: 'os' module has no attribute 'kf' >>> pow(3,4,0) Traceback (most recent call last): File "", line 1, in ? ValueError: pow() arg 3 cannot be 0 >>> os.execv('a', 3) Traceback (most recent call last): File "", line 1, in ? TypeError: execv() arg 2 must be a tuple or list >>> os.execv('a', (3,4)) Traceback (most recent call last): File "", line 1, in ? TypeError: execv() arg 2 must contain only strings >>> 0 ** -4 Traceback (most recent call last): File "", line 1, in ? ZeroDivisionError: cannot raise 0 to a negative power >>> int("45", 1) Traceback (most recent call last): File "", line 1, in ? ValueError: int() base must be >= 2 and <= 36 >>> ord(3) Traceback (most recent call last): File "", line 1, in ? TypeError: ord() expected string or Unicode character, int found ------------------------------------------------------- Date: 2000-Oct-08 20:28 By: ping Comment: Forgot to mention that this patch also includes changed names for audio formats in the linuxaudiodev module. ------------------------------------------------------- Date: 2000-Oct-09 05:32 By: gvanrossum Comment: Sorry, but this has to go in after 2.0 final is released. It's touching way too much code to be snuck in at the very last moment. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101839&group_id=5470 From noreply@sourceforge.net Mon Oct 9 13:46:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 05:46:06 -0700 Subject: [Patches] [Patch #101842] Localization of calendar module. Message-ID: <200010091246.FAA06693@bush.i.sourceforge.net> Patch #101842 has been updated. Project: Category: library Status: Postponed Summary: Localization of calendar module. Follow-Ups: Date: 2000-Oct-09 01:34 By: ods Comment: This work fine for all locales on NT, but may work a bit strange with some locales (e.g. ru_RU) on some platforms with buggy (IMHO) L10n of strftime (e.g. RedHat Linux). ------------------------------------------------------- Date: 2000-Oct-09 05:46 By: gvanrossum Comment: This seems a little too much code while we're in a feature freeze. Let's do this after 2.0final is released. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101842&group_id=5470 From noreply@sourceforge.net Mon Oct 9 14:49:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 06:49:21 -0700 Subject: [Patches] [Patch #101807] Patch for SRE character class bug (#116251) Message-ID: <200010091349.GAA02418@delerium.i.sourceforge.net> Patch #101807 has been updated. Project: Category: library Status: Closed Summary: Patch for SRE character class bug (#116251) Follow-Ups: Date: 2000-Oct-09 06:49 By: gvanrossum Comment: Checked in (by effbot). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101807&group_id=5470 From noreply@sourceforge.net Mon Oct 9 14:58:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 06:58:15 -0700 Subject: [Patches] [Patch #101816] Fixes shared modules on Mac OS X Message-ID: <200010091358.GAA02687@delerium.i.sourceforge.net> Patch #101816 has been updated. Project: Category: None Status: Open Summary: Fixes shared modules on Mac OS X Follow-Ups: Date: 2000-Oct-06 20:47 By: tonylownds Comment: Martin v. Loewis suggested I post this patch; it changes configure.in and configure: 1. Mac OS X is recognized by the Next-ish host recognition code as "darwin/1.2" 2. When specifying just --with-dyld, modules can compile as shared 3. --with-dyld and --with-next-framework, modules can compile as shared 4. --with-suffix=.exe, and Lib/plat-darwin1.2 is being made, the regen script invokes python as python.exe ------------------------------------------------------- Date: 2000-Oct-06 20:54 By: tonylownds Comment: New version does not patch configure, as this was 160 needless kb. New version is 4181 bytes. ------------------------------------------------------- Date: 2000-Oct-07 08:23 By: none Comment: 1) some of the fixes have previously been checked in. 2) uname of release is Darwin not darwin 3) it looks as if this patch is corrupted ------------------------------------------------------- Date: 2000-Oct-07 11:07 By: none Comment: 1) some of the fixes have previously been checked in. 2) uname of release is Darwin not darwin 3) it looks as if this patch is corrupted ------------------------------------------------------- Date: 2000-Oct-08 16:31 By: none Comment: Redid patch against an up-to-date CVS tree ------------------------------------------------------- Date: 2000-Oct-08 16:33 By: tonylownds Comment: Re-did patch against an updated CVS checkout. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101816&group_id=5470 From noreply@sourceforge.net Mon Oct 9 15:00:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 07:00:31 -0700 Subject: [Patches] [Patch #101823] Fix Darwin POSIX Thread redefinition Message-ID: <200010091400.HAA02834@delerium.i.sourceforge.net> Patch #101823 has been updated. Project: Category: None Status: Open Summary: Fix Darwin POSIX Thread redefinition Follow-Ups: Date: 2000-Oct-07 11:40 By: dkwolfe Comment: Oh, one other thing. The patch does not include the changes to configure - you'll need to run autoconf to make those changes. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101823&group_id=5470 From noreply@sourceforge.net Mon Oct 9 15:19:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 07:19:12 -0700 Subject: [Patches] [Patch #101843] Remove all uses of "assert" from the test suite Message-ID: <200010091419.HAA03593@delerium.i.sourceforge.net> Patch #101843 has been updated. Project: Category: core (C code) Status: Open Summary: Remove all uses of "assert" from the test suite ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101843&group_id=5470 From noreply@sourceforge.net Mon Oct 9 15:25:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 07:25:00 -0700 Subject: [Patches] [Patch #101843] Remove all uses of "assert" from the test suite Message-ID: <200010091425.HAA03857@delerium.i.sourceforge.net> Patch #101843 has been updated. Project: Category: core (C code) Status: Open Summary: Remove all uses of "assert" from the test suite Follow-Ups: Date: 2000-Oct-09 07:25 By: lemburg Comment: This patch removes all uses of the assert statement from the regression test suite. Use of assert in the suite is depreciated due to asserts being removed from the byte code when Python is run in optimized mode. The patch adds a new function to test_support (verify) which handles the asserts in a more customizable way. It does not rely on the assert statement. I have tested this patch lightly (meaning that the suite runs through just fine). Not all execution paths are testable due to the nature of the patch, though. Please review. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101843&group_id=5470 From noreply@sourceforge.net Mon Oct 9 16:28:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 08:28:12 -0700 Subject: [Patches] [Patch #101840] Minor fix in documentation of calendar module. Message-ID: <200010091528.IAA06417@delerium.i.sourceforge.net> Patch #101840 has been updated. Project: Category: documentation Status: Closed Summary: Minor fix in documentation of calendar module. Follow-Ups: Date: 2000-Oct-09 08:28 By: fdrake Comment: Checked in as Doc/lib/libcalendar.tex revision 1.9. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101840&group_id=5470 From noreply@sourceforge.net Mon Oct 9 16:59:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 08:59:58 -0700 Subject: [Patches] [Patch #101774] revise BeOS build Message-ID: <200010091559.IAA07750@delerium.i.sourceforge.net> Patch #101774 has been updated. Project: Category: Build Status: Accepted Summary: revise BeOS build ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101774&group_id=5470 From noreply@sourceforge.net Mon Oct 9 16:59:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 08:59:58 -0700 Subject: [Patches] [Patch #101775] revise BeOS build Message-ID: <200010091559.IAA07753@delerium.i.sourceforge.net> Patch #101775 has been updated. Project: Category: Build Status: Accepted Summary: revise BeOS build ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101775&group_id=5470 From noreply@sourceforge.net Mon Oct 9 16:59:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 08:59:59 -0700 Subject: [Patches] [Patch #101776] revise BeOS build Message-ID: <200010091559.IAA07756@delerium.i.sourceforge.net> Patch #101776 has been updated. Project: Category: Build Status: Accepted Summary: revise BeOS build ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101776&group_id=5470 From noreply@sourceforge.net Mon Oct 9 17:00:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 09:00:00 -0700 Subject: [Patches] [Patch #101777] revise BeOS build Message-ID: <200010091600.JAA07761@delerium.i.sourceforge.net> Patch #101777 has been updated. Project: Category: Build Status: Accepted Summary: revise BeOS build ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101777&group_id=5470 From noreply@sourceforge.net Mon Oct 9 17:00:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 09:00:00 -0700 Subject: [Patches] [Patch #101778] revise BeOS build Message-ID: <200010091600.JAA07764@delerium.i.sourceforge.net> Patch #101778 has been updated. Project: Category: Build Status: Accepted Summary: revise BeOS build ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101778&group_id=5470 From donn@u.washington.edu Mon Oct 9 17:42:28 2000 From: donn@u.washington.edu (Donn Cave) Date: Mon, 9 Oct 2000 09:42:28 -0700 Subject: [Patches] Re: [Patch #101774] revise BeOS build (et al.) - summary Message-ID: <200010091642.JAA01190@mailhost1.u.washington.edu> I hope this isn't eating into the release schedule too much, but it's great to see these late patches get considered. I tried to email some remarks along these lines after I pasted the patches in, but obviously they didn't reach anyone. - dl_export.h wasn't installed properly (in the wrong place) - Build didn't work on BeOS PowerPC architecture * Eliminate dl_export.h and its include in config.h, which was only ever needed on PowerPC anyway. Shift these defines to $(OPT) during configure. * Replace Chris Herborth's heroic ar-fake with a silly ar-fake that just uses a directory. libpython.a is never used for anything but shuffling object files, libpython.so is built at the end. (Also very expedient, other architectures may use if they like.) * Add make libpython.so target in top Makefile. * Change rm -f libpython.a to rm -rf libpython.a, in Modules/Makefile * Obsoleted special LINKCC script. Removed some unnecessary BeOS stuff from configure, shifted other parts to group with similar things. * Removed force MACHDEP to "beos" - no strong feelings about this, but for me it the standard Python usage makes sense, beos4, beos5 etc. What happened to Chris Herborth - Don't know. I have corresponded with him in the past, but in this matter haven't had any response after at least a week. BeOS current state: two releases in use, 4.5 and 5.0, mostly the latter but a fair number still at 4.5 and with compilers. Differences between the two releases don't affect the Python build. Two hardware architectures in use, PPC and Intel. Mostly the latter and the PPC architecture is officially facing a support sunset but still in common use among early adopters. Thanks, Donn Cave, donn@oz.net From noreply@sourceforge.net Mon Oct 9 17:46:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 09:46:45 -0700 Subject: [Patches] [Patch #101778] revise BeOS build Message-ID: <200010091646.JAA09745@delerium.i.sourceforge.net> Patch #101778 has been updated. Project: Category: Build Status: Closed Summary: revise BeOS build Follow-Ups: Date: 2000-Oct-09 09:46 By: fdrake Comment: Checked in as BeOS/ar-fake revision 1.4. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101778&group_id=5470 From noreply@sourceforge.net Mon Oct 9 17:48:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 09:48:34 -0700 Subject: [Patches] [Patch #101777] revise BeOS build Message-ID: <200010091648.JAA09800@delerium.i.sourceforge.net> Patch #101777 has been updated. Project: Category: Build Status: Closed Summary: revise BeOS build Follow-Ups: Date: 2000-Oct-09 09:48 By: fdrake Comment: Checked in as Modules/Makefile.pre.in revision 1.68. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101777&group_id=5470 From noreply@sourceforge.net Mon Oct 9 17:52:20 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 09:52:20 -0700 Subject: [Patches] [Patch #101776] revise BeOS build Message-ID: <200010091652.JAA10013@delerium.i.sourceforge.net> Patch #101776 has been updated. Project: Category: Build Status: Closed Summary: revise BeOS build Follow-Ups: Date: 2000-Oct-09 09:52 By: fdrake Comment: Checked in as Makefile.in revision 1.105. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101776&group_id=5470 From noreply@sourceforge.net Mon Oct 9 18:02:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 10:02:21 -0700 Subject: [Patches] [Patch #101775] revise BeOS build Message-ID: <200010091702.KAA10419@delerium.i.sourceforge.net> Patch #101775 has been updated. Project: Category: Build Status: Closed Summary: revise BeOS build Follow-Ups: Date: 2000-Oct-09 10:02 By: fdrake Comment: Checked in as acconfig.h revision 1.39 and config.h.in revision 2.76. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101775&group_id=5470 From noreply@sourceforge.net Mon Oct 9 18:07:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 10:07:58 -0700 Subject: [Patches] [Patch #101774] revise BeOS build Message-ID: <200010091707.KAA10669@delerium.i.sourceforge.net> Patch #101774 has been updated. Project: Category: Build Status: Closed Summary: revise BeOS build Follow-Ups: Date: 2000-Oct-09 10:07 By: fdrake Comment: Checked in as configure.in revision 1.169. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101774&group_id=5470 From fdrake@beopen.com Mon Oct 9 18:09:06 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 9 Oct 2000 13:09:06 -0400 (EDT) Subject: [Patches] Re: [Patch #101774] revise BeOS build (et al.) - summary In-Reply-To: <200010091642.JAA01190@mailhost1.u.washington.edu> References: <200010091642.JAA01190@mailhost1.u.washington.edu> Message-ID: <14817.64434.91528.568825@cj42289-a.reston1.va.home.com> The patches are in; Donn, please check everything that's in CVS right now and let us know if there are any problems on BeOS. I don't know that we'll be able to fix them, but a last-minute check won't hurt. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From jeremy@beopen.com Mon Oct 9 18:32:27 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Mon, 9 Oct 2000 13:32:27 -0400 (EDT) Subject: [Patches] Re: [Patch #101774] revise BeOS build (et al.) - summary In-Reply-To: <200010091642.JAA01190@mailhost1.u.washington.edu> References: <200010091642.JAA01190@mailhost1.u.washington.edu> Message-ID: <14818.299.176870.745204@bitdiddle.concentric.net> Donn, Could you write up a short description of the BeOS changes suitable for inclusion in the Python NEWS file. Jeremy From noreply@sourceforge.net Mon Oct 9 18:49:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 10:49:50 -0700 Subject: [Patches] [Patch #101844] bdist_wininst creates corrupt installations Message-ID: <200010091749.KAA18883@bush.i.sourceforge.net> Patch #101844 has been updated. Project: Category: distutils Status: Open Summary: bdist_wininst creates corrupt installations ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101844&group_id=5470 From noreply@sourceforge.net Mon Oct 9 18:59:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 10:59:08 -0700 Subject: [Patches] [Patch #101782] Enhances 1.6 compiler to raise 'proper' SyntaxErrors Message-ID: <200010091759.KAA19294@bush.i.sourceforge.net> Patch #101782 has been updated. Project: Category: Parser/Compiler Status: Postponed Summary: Enhances 1.6 compiler to raise 'proper' SyntaxErrors Follow-Ups: Date: 2000-Oct-04 12:29 By: Roman_Sulzhyk Comment: Hello: There's a problem with the compiler.c (which persists in 2.0 also) which means it raises 'old style' SyntaxErrors, which could not be formatted properly. I mentioned this to Guido during the last conference, and he said it can best be done by moving parts of the 'linecache' functionality to core python, or something along those lines. Well, I've put together something which is not so far-fetching, but plugs this hole. The only time it reverts to the 'old style' compile error is when the input file is not a regular file (like stdin), since the line information is lost at that point - don't think parser.c saves it anywhere. Tell me what you think - should I port it to 2.0, or just drop it altogether if it's not needed. Thanks, Roman ------------------------------------------------------- Date: 2000-Oct-04 23:40 By: fdrake Comment: This needs to be ported to the latest CVS version before being considered for implementation (but discussion of the feature is welcome!). This cannot be considered for inclusion in 2.0 since we're in feature freeze already, and are only fixing bugs at this point. This can be considered for 2.1. Marking as postponed. ------------------------------------------------------- Date: 2000-Oct-09 10:59 By: Roman_Sulzhyk Comment: I've ported it to the latest CVS version - check it out, Roman ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101782&group_id=5470 From noreply@sourceforge.net Mon Oct 9 18:59:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 10:59:07 -0700 Subject: [Patches] [Patch #101782] Enhances 1.6 compiler to raise 'proper' SyntaxErrors Message-ID: <200010091759.KAA19291@bush.i.sourceforge.net> Patch #101782 has been updated. Project: Category: Parser/Compiler Status: Postponed Summary: Enhances 1.6 compiler to raise 'proper' SyntaxErrors Follow-Ups: Date: 2000-Oct-04 12:29 By: Roman_Sulzhyk Comment: Hello: There's a problem with the compiler.c (which persists in 2.0 also) which means it raises 'old style' SyntaxErrors, which could not be formatted properly. I mentioned this to Guido during the last conference, and he said it can best be done by moving parts of the 'linecache' functionality to core python, or something along those lines. Well, I've put together something which is not so far-fetching, but plugs this hole. The only time it reverts to the 'old style' compile error is when the input file is not a regular file (like stdin), since the line information is lost at that point - don't think parser.c saves it anywhere. Tell me what you think - should I port it to 2.0, or just drop it altogether if it's not needed. Thanks, Roman ------------------------------------------------------- Date: 2000-Oct-04 23:40 By: fdrake Comment: This needs to be ported to the latest CVS version before being considered for implementation (but discussion of the feature is welcome!). This cannot be considered for inclusion in 2.0 since we're in feature freeze already, and are only fixing bugs at this point. This can be considered for 2.1. Marking as postponed. ------------------------------------------------------- Date: 2000-Oct-09 10:59 By: Roman_Sulzhyk Comment: I've ported it to the latest CVS version - check it out, Roman ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101782&group_id=5470 From noreply@sourceforge.net Mon Oct 9 19:13:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 11:13:49 -0700 Subject: [Patches] [Patch #101844] bdist_wininst creates corrupt installations Message-ID: <200010091813.LAA19948@bush.i.sourceforge.net> Patch #101844 has been updated. Project: Category: distutils Status: Open Summary: bdist_wininst creates corrupt installations Follow-Ups: Date: 2000-Oct-09 11:13 By: theller Comment: [Martin von Loewis] > I've created a PyXML distribution with recent distutils (0.93 and > 1.0). When installing these distributions, the installer creates empty > files only, see > > http://download.sourceforge.net/pyxml/PyXML-0.6.0.win32.exe > > for an example. > > I've tracked this down to usage of the zipfile module. If it does not > find an external zip program (which I did not have), it then tries to > use the zipfile module. Somehow, the installation program later cannot > process the files created with that module. > > The problem is probably in the installer, since Winzip 7 is capable of > reading the package, and extracts the files properly. > > I have solved the problem by installing infozip on my > machine. However, I'd appreciate if somebody could look into the > problem and let me know what the cause is. If you cannot reproduce the > problem, please let me know as well. > The problem was that the windows installer was using zipfile datastructures which are not always set. The following patch fixes this problem. Since currently I cannot check in these changes, I'm posting them here so they do not get lost. Note that wininst.exe must be recompiled and bdist_wininst.py must be regenerated to complete the fix. Thomas ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101844&group_id=5470 From donn@u.washington.edu Mon Oct 9 19:29:16 2000 From: donn@u.washington.edu (Donn Cave) Date: Mon, 9 Oct 2000 11:29:16 -0700 Subject: [Patches] Re: [Patch #101774] revise BeOS build (et al.) - summary Message-ID: <200010091829.LAA21770@mailhost1.u.washington.edu> BeOS Changes ------------ Changes to Python build. ar-fake now operates on a directory of object files. dl_export.h is gone, and its macros now appear on the mwcc command line during build on PPC BeOS. Platform directory in lib/python2.0 is "plat-beos5" (or "plat-beos4", if building on BeOS 4.5), rather than "plat-beos". ------------- Hope that works for NEWS, feel free to edit as necessary. Thanks, Donn Cave, donn@oz.net From noreply@sourceforge.net Mon Oct 9 20:26:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 12:26:09 -0700 Subject: [Patches] [Patch #101843] Remove all uses of "assert" from the test suite Message-ID: <200010091926.MAA16582@delerium.i.sourceforge.net> Patch #101843 has been updated. Project: Category: core (C code) Status: Postponed Summary: Remove all uses of "assert" from the test suite Follow-Ups: Date: 2000-Oct-09 07:25 By: lemburg Comment: This patch removes all uses of the assert statement from the regression test suite. Use of assert in the suite is depreciated due to asserts being removed from the byte code when Python is run in optimized mode. The patch adds a new function to test_support (verify) which handles the asserts in a more customizable way. It does not rely on the assert statement. I have tested this patch lightly (meaning that the suite runs through just fine). Not all execution paths are testable due to the nature of the patch, though. Please review. ------------------------------------------------------- Date: 2000-Oct-09 12:26 By: gvanrossum Comment: Great! But let's do this post-2.0 final release. I'm really getting worried about patches that touch every file in a particular corner of the universe... :-( ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101843&group_id=5470 From noreply@sourceforge.net Mon Oct 9 20:26:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 12:26:23 -0700 Subject: [Patches] [Patch #101824] On Darwin, remove unrecognized option `-OPT:Olimit=0' Message-ID: <200010091926.MAA16597@delerium.i.sourceforge.net> Patch #101824 has been updated. Project: Category: None Status: Open Summary: On Darwin, remove unrecognized option `-OPT:Olimit=0' ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101824&group_id=5470 From noreply@sourceforge.net Mon Oct 9 20:28:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 12:28:08 -0700 Subject: [Patches] [Patch #101844] bdist_wininst creates corrupt installations Message-ID: <200010091928.MAA16631@delerium.i.sourceforge.net> Patch #101844 has been updated. Project: Category: distutils Status: Open Summary: bdist_wininst creates corrupt installations Follow-Ups: Date: 2000-Oct-09 11:13 By: theller Comment: [Martin von Loewis] > I've created a PyXML distribution with recent distutils (0.93 and > 1.0). When installing these distributions, the installer creates empty > files only, see > > http://download.sourceforge.net/pyxml/PyXML-0.6.0.win32.exe > > for an example. > > I've tracked this down to usage of the zipfile module. If it does not > find an external zip program (which I did not have), it then tries to > use the zipfile module. Somehow, the installation program later cannot > process the files created with that module. > > The problem is probably in the installer, since Winzip 7 is capable of > reading the package, and extracts the files properly. > > I have solved the problem by installing infozip on my > machine. However, I'd appreciate if somebody could look into the > problem and let me know what the cause is. If you cannot reproduce the > problem, please let me know as well. > The problem was that the windows installer was using zipfile datastructures which are not always set. The following patch fixes this problem. Since currently I cannot check in these changes, I'm posting them here so they do not get lost. Note that wininst.exe must be recompiled and bdist_wininst.py must be regenerated to complete the fix. Thomas ------------------------------------------------------- Date: 2000-Oct-09 12:28 By: gvanrossum Comment: Hopefully Greg Ward will eb back to review this before 2.0 *final* goes out on Oct 16. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101844&group_id=5470 From fdrake@beopen.com Mon Oct 9 20:27:15 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 9 Oct 2000 15:27:15 -0400 (EDT) Subject: [Patches] Re: [Patch #101774] revise BeOS build (et al.) - summary In-Reply-To: <200010091829.LAA21770@mailhost1.u.washington.edu> References: <200010091829.LAA21770@mailhost1.u.washington.edu> Message-ID: <14818.7187.462168.418021@cj42289-a.reston1.va.home.com> Donn Cave writes: > Platform directory in lib/python2.0 is "plat-beos5" (or "plat-beos4", > if building on BeOS 4.5), rather than "plat-beos". I don't recall seeing anything about a plat-beos4 in the patches. Are you sure this works? Is the plat-beos4/ directory getting populated properly, or does the end user need to run regen? -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From thomas@xs4all.net Mon Oct 9 20:50:11 2000 From: thomas@xs4all.net (Thomas Wouters) Date: Mon, 9 Oct 2000 21:50:11 +0200 Subject: [Patches] Re: [Patch #101774] revise BeOS build (et al.) - summary In-Reply-To: <14818.7187.462168.418021@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Mon, Oct 09, 2000 at 03:27:15PM -0400 References: <200010091829.LAA21770@mailhost1.u.washington.edu> <14818.7187.462168.418021@cj42289-a.reston1.va.home.com> Message-ID: <20001009215011.N12812@xs4all.nl> On Mon, Oct 09, 2000 at 03:27:15PM -0400, Fred L. Drake, Jr. wrote: > Donn Cave writes: > > Platform directory in lib/python2.0 is "plat-beos5" (or "plat-beos4", > > if building on BeOS 4.5), rather than "plat-beos". > I don't recall seeing anything about a plat-beos4 in the patches. > Are you sure this works? Is the plat-beos4/ directory getting > populated properly, or does the end user need to run regen? Which reminds me of something I've wanted to look at for a while, but will have to wait for after 2.0 now: plat-$arch should be generated (when missing) not only on 'make install' but also on 'make test', otherwise tests that need one of those files (test_fcntl, for instance) will fail. Not a big issue, but not worth not fixing either ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From noreply@sourceforge.net Mon Oct 9 20:53:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 12:53:07 -0700 Subject: [Patches] [Patch #101823] Fix Darwin POSIX Thread redefinition Message-ID: <200010091953.MAA24186@bush.i.sourceforge.net> Patch #101823 has been updated. Project: Category: Build Status: Closed Summary: Fix Darwin POSIX Thread redefinition Follow-Ups: Date: 2000-Oct-07 11:40 By: dkwolfe Comment: Oh, one other thing. The patch does not include the changes to configure - you'll need to run autoconf to make those changes. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101823&group_id=5470 From noreply@sourceforge.net Mon Oct 9 20:53:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 12:53:06 -0700 Subject: [Patches] [Patch #101816] Fixes shared modules on Mac OS X Message-ID: <200010091953.MAA24183@bush.i.sourceforge.net> Patch #101816 has been updated. Project: Category: Build Status: Closed Summary: Fixes shared modules on Mac OS X Follow-Ups: Date: 2000-Oct-06 20:47 By: tonylownds Comment: Martin v. Loewis suggested I post this patch; it changes configure.in and configure: 1. Mac OS X is recognized by the Next-ish host recognition code as "darwin/1.2" 2. When specifying just --with-dyld, modules can compile as shared 3. --with-dyld and --with-next-framework, modules can compile as shared 4. --with-suffix=.exe, and Lib/plat-darwin1.2 is being made, the regen script invokes python as python.exe ------------------------------------------------------- Date: 2000-Oct-06 20:54 By: tonylownds Comment: New version does not patch configure, as this was 160 needless kb. New version is 4181 bytes. ------------------------------------------------------- Date: 2000-Oct-07 08:23 By: none Comment: 1) some of the fixes have previously been checked in. 2) uname of release is Darwin not darwin 3) it looks as if this patch is corrupted ------------------------------------------------------- Date: 2000-Oct-07 11:07 By: none Comment: 1) some of the fixes have previously been checked in. 2) uname of release is Darwin not darwin 3) it looks as if this patch is corrupted ------------------------------------------------------- Date: 2000-Oct-08 16:31 By: none Comment: Redid patch against an up-to-date CVS tree ------------------------------------------------------- Date: 2000-Oct-08 16:33 By: tonylownds Comment: Re-did patch against an updated CVS checkout. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101816&group_id=5470 From noreply@sourceforge.net Mon Oct 9 20:53:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 12:53:07 -0700 Subject: [Patches] [Patch #101824] On Darwin, remove unrecognized option `-OPT:Olimit=0' Message-ID: <200010091953.MAA24189@bush.i.sourceforge.net> Patch #101824 has been updated. Project: Category: Build Status: Closed Summary: On Darwin, remove unrecognized option `-OPT:Olimit=0' ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101824&group_id=5470 From noreply@sourceforge.net Mon Oct 9 20:55:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 12:55:00 -0700 Subject: [Patches] [Patch #101844] bdist_wininst creates corrupt installations Message-ID: <200010091955.MAA17811@delerium.i.sourceforge.net> Patch #101844 has been updated. Project: Category: distutils Status: Open Summary: bdist_wininst creates corrupt installations Follow-Ups: Date: 2000-Oct-09 11:13 By: theller Comment: [Martin von Loewis] > I've created a PyXML distribution with recent distutils (0.93 and > 1.0). When installing these distributions, the installer creates empty > files only, see > > http://download.sourceforge.net/pyxml/PyXML-0.6.0.win32.exe > > for an example. > > I've tracked this down to usage of the zipfile module. If it does not > find an external zip program (which I did not have), it then tries to > use the zipfile module. Somehow, the installation program later cannot > process the files created with that module. > > The problem is probably in the installer, since Winzip 7 is capable of > reading the package, and extracts the files properly. > > I have solved the problem by installing infozip on my > machine. However, I'd appreciate if somebody could look into the > problem and let me know what the cause is. If you cannot reproduce the > problem, please let me know as well. > The problem was that the windows installer was using zipfile datastructures which are not always set. The following patch fixes this problem. Since currently I cannot check in these changes, I'm posting them here so they do not get lost. Note that wininst.exe must be recompiled and bdist_wininst.py must be regenerated to complete the fix. Thomas ------------------------------------------------------- Date: 2000-Oct-09 12:28 By: gvanrossum Comment: Hopefully Greg Ward will eb back to review this before 2.0 *final* goes out on Oct 16. ------------------------------------------------------- Date: 2000-Oct-09 12:54 By: akuchling Comment: Greg is supposed to be getting back around Friday the 13th. (Hmmm...) So the schedule will be tight, but I don't think Greg can do much checking on the Windows install; since the patch is from Thomas, he'll probably just trust it. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101844&group_id=5470 From noreply@sourceforge.net Mon Oct 9 21:08:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 13:08:00 -0700 Subject: [Patches] [Patch #101774] revise BeOS build Message-ID: <200010092008.NAA18319@delerium.i.sourceforge.net> Patch #101774 has been updated. Project: Category: Build Status: Closed Summary: revise BeOS build Follow-Ups: Date: 2000-Oct-09 10:07 By: fdrake Comment: Checked in as configure.in revision 1.169. ------------------------------------------------------- Date: 2000-Oct-09 13:07 By: donnc Comment: Oct 9 configure.in retains extraneous AC_DEFINE(DL_EXPORT_HEADER,"dl_export.h") at line 131 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101774&group_id=5470 From noreply@sourceforge.net Mon Oct 9 21:08:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 13:08:00 -0700 Subject: [Patches] [Patch #101774] revise BeOS build Message-ID: <200010092008.NAA18322@delerium.i.sourceforge.net> Patch #101774 has been updated. Project: Category: Build Status: Closed Summary: revise BeOS build Follow-Ups: Date: 2000-Oct-09 10:07 By: fdrake Comment: Checked in as configure.in revision 1.169. ------------------------------------------------------- Date: 2000-Oct-09 13:07 By: donnc Comment: Oct 9 configure.in retains extraneous AC_DEFINE(DL_EXPORT_HEADER,"dl_export.h") at line 131 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101774&group_id=5470 From noreply@sourceforge.net Mon Oct 9 21:44:51 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 13:44:51 -0700 Subject: [Patches] [Patch #101844] bdist_wininst creates corrupt installations Message-ID: <200010092044.NAA26402@bush.i.sourceforge.net> Patch #101844 has been updated. Project: Category: distutils Status: Open Summary: bdist_wininst creates corrupt installations Follow-Ups: Date: 2000-Oct-09 11:13 By: theller Comment: [Martin von Loewis] > I've created a PyXML distribution with recent distutils (0.93 and > 1.0). When installing these distributions, the installer creates empty > files only, see > > http://download.sourceforge.net/pyxml/PyXML-0.6.0.win32.exe > > for an example. > > I've tracked this down to usage of the zipfile module. If it does not > find an external zip program (which I did not have), it then tries to > use the zipfile module. Somehow, the installation program later cannot > process the files created with that module. > > The problem is probably in the installer, since Winzip 7 is capable of > reading the package, and extracts the files properly. > > I have solved the problem by installing infozip on my > machine. However, I'd appreciate if somebody could look into the > problem and let me know what the cause is. If you cannot reproduce the > problem, please let me know as well. > The problem was that the windows installer was using zipfile datastructures which are not always set. The following patch fixes this problem. Since currently I cannot check in these changes, I'm posting them here so they do not get lost. Note that wininst.exe must be recompiled and bdist_wininst.py must be regenerated to complete the fix. Thomas ------------------------------------------------------- Date: 2000-Oct-09 12:28 By: gvanrossum Comment: Hopefully Greg Ward will eb back to review this before 2.0 *final* goes out on Oct 16. ------------------------------------------------------- Date: 2000-Oct-09 12:54 By: akuchling Comment: Greg is supposed to be getting back around Friday the 13th. (Hmmm...) So the schedule will be tight, but I don't think Greg can do much checking on the Windows install; since the patch is from Thomas, he'll probably just trust it. ------------------------------------------------------- Date: 2000-Oct-09 13:44 By: jhylton Comment: Thomas, I have no idea how to apply this patch. I can't find the files mentioned anywhere in the Python CVS tree. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101844&group_id=5470 From noreply@sourceforge.net Mon Oct 9 21:58:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 13:58:56 -0700 Subject: [Patches] [Patch #101844] bdist_wininst creates corrupt installations Message-ID: <200010092058.NAA20469@delerium.i.sourceforge.net> Patch #101844 has been updated. Project: Category: distutils Status: Open Summary: bdist_wininst creates corrupt installations Follow-Ups: Date: 2000-Oct-09 11:13 By: theller Comment: [Martin von Loewis] > I've created a PyXML distribution with recent distutils (0.93 and > 1.0). When installing these distributions, the installer creates empty > files only, see > > http://download.sourceforge.net/pyxml/PyXML-0.6.0.win32.exe > > for an example. > > I've tracked this down to usage of the zipfile module. If it does not > find an external zip program (which I did not have), it then tries to > use the zipfile module. Somehow, the installation program later cannot > process the files created with that module. > > The problem is probably in the installer, since Winzip 7 is capable of > reading the package, and extracts the files properly. > > I have solved the problem by installing infozip on my > machine. However, I'd appreciate if somebody could look into the > problem and let me know what the cause is. If you cannot reproduce the > problem, please let me know as well. > The problem was that the windows installer was using zipfile datastructures which are not always set. The following patch fixes this problem. Since currently I cannot check in these changes, I'm posting them here so they do not get lost. Note that wininst.exe must be recompiled and bdist_wininst.py must be regenerated to complete the fix. Thomas ------------------------------------------------------- Date: 2000-Oct-09 12:28 By: gvanrossum Comment: Hopefully Greg Ward will eb back to review this before 2.0 *final* goes out on Oct 16. ------------------------------------------------------- Date: 2000-Oct-09 12:54 By: akuchling Comment: Greg is supposed to be getting back around Friday the 13th. (Hmmm...) So the schedule will be tight, but I don't think Greg can do much checking on the Windows install; since the patch is from Thomas, he'll probably just trust it. ------------------------------------------------------- Date: 2000-Oct-09 13:44 By: jhylton Comment: Thomas, I have no idea how to apply this patch. I can't find the files mentioned anywhere in the Python CVS tree. ------------------------------------------------------- Date: 2000-Oct-09 13:58 By: jhylton Comment: AMK points out that this is a patch against some distutils source tree stored elsewhere. The code it patches is included as a base64 encoded string in the Python code. Wow! The sheer vulgarity of this impresses me. I think we should integrate the actual source code into the CVS tree when Greg gets back. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101844&group_id=5470 From donn@u.washington.edu Mon Oct 9 22:15:53 2000 From: donn@u.washington.edu (Donn Cave) Date: Mon, 9 Oct 2000 14:15:53 -0700 Subject: [Patches] Re: [Patch #101774] revise BeOS build (et al.) - summary Message-ID: <200010092115.OAA18673@mailhost1.u.washington.edu> | The patches are in; Donn, please check everything that's in CVS | right now and let us know if there are any problems on BeOS. I don't | know that we'll be able to fix them, but a last-minute check won't | hurt. I have built and installed on PPC and Intel platforms, and built some external stuff on Intel just to see if config.h etc. works. Only one problem noted, an extraneous line in configure.in (and hence configure.) Otherwise, builds and installs correctly. *** configure.in.dist Mon Oct 9 10:06:13 2000 --- configure.in Mon Oct 9 13:02:58 2000 *************** *** 128,134 **** AR="$PWD/BeOS/ar-fake" RANLIB=: - AC_DEFINE(DL_EXPORT_HEADER,"dl_export.h") ;; x86) CC=gcc --- 128,133 ---- This dl_export.h file is obsoleted by the changes I submitted. I didn't check to see whether the above line is fatal, but I think it isn't - it doesn't do anything, because nothing uses DL_EXPORT_HEADER. Thanks, Donn Cave, donn@oz.net From fdrake@beopen.com Mon Oct 9 22:24:32 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 9 Oct 2000 17:24:32 -0400 (EDT) Subject: [Patches] Re: [Patch #101774] revise BeOS build (et al.) - summary In-Reply-To: <200010092115.OAA18673@mailhost1.u.washington.edu> References: <200010092115.OAA18673@mailhost1.u.washington.edu> Message-ID: <14818.14224.337943.993967@cj42289-a.reston1.va.home.com> Donn Cave writes: > Only one problem noted, an extraneous line in configure.in (and > hence configure.) Otherwise, builds and installs correctly. I've already removed this in CVS; thanks! > This dl_export.h file is obsoleted by the changes I submitted. > I didn't check to see whether the above line is fatal, but I > think it isn't - it doesn't do anything, because nothing uses > DL_EXPORT_HEADER. I've now removed this from CVS. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From donn@u.washington.edu Mon Oct 9 22:29:33 2000 From: donn@u.washington.edu (Donn Cave) Date: Mon, 9 Oct 2000 14:29:33 -0700 Subject: [Patches] Re: [Patch #101774] revise BeOS build (et al.) - summary Message-ID: <200010092129.OAA21327@mailhost1.u.washington.edu> Quoth "Fred L. Drake, Jr." : | | Donn Cave writes: | > Platform directory in lib/python2.0 is "plat-beos5" (or "plat-beos4", | > if building on BeOS 4.5), rather than "plat-beos". | | I don't recall seeing anything about a plat-beos4 in the patches. | Are you sure this works? Is the plat-beos4/ directory getting | populated properly, or does the end user need to run regen? Right, on anything but v5, user would need to make the directory and run regen on his own. Possibly questionable decision on my part, I could have added plat-beos4 to the issue either with 101781 or later, but decided not to plague you with it. BeOS 5 has been out for a long time. I can generate the modules for plat-beos4, but unfortunately not right now, it would be at least 8 hours from now if today at all. The regen is the same. Donn Cave, donn@oz.net From fdrake@beopen.com Mon Oct 9 22:32:30 2000 From: fdrake@beopen.com (Fred L. Drake, Jr.) Date: Mon, 9 Oct 2000 17:32:30 -0400 (EDT) Subject: [Patches] Re: [Patch #101774] revise BeOS build (et al.) - summary In-Reply-To: <200010092129.OAA21327@mailhost1.u.washington.edu> References: <200010092129.OAA21327@mailhost1.u.washington.edu> Message-ID: <14818.14702.115350.20531@cj42289-a.reston1.va.home.com> Donn Cave writes: > Right, on anything but v5, user would need to make the directory and > run regen on his own. Possibly questionable decision on my part, > I could have added plat-beos4 to the issue either with 101781 or later, > but decided not to plague you with it. BeOS 5 has been out for a > long time. I can generate the modules for plat-beos4, but > unfortunately not right now, it would be at least 8 hours from now > if today at all. The regen is the same. Then let's skip it unless there's a public outcry. There's not time to get it into the release candidate. Thanks for answering all our questions! -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member From noreply@sourceforge.net Mon Oct 9 23:26:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 15:26:41 -0700 Subject: [Patches] [Patch #101850] Documentation for SAX2 Message-ID: <200010092226.PAA30642@bush.i.sourceforge.net> Patch #101850 has been updated. Project: Category: documentation Status: Open Summary: Documentation for SAX2 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101850&group_id=5470 From noreply@sourceforge.net Tue Oct 10 00:37:51 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 16:37:51 -0700 Subject: [Patches] [Patch #101844] bdist_wininst creates corrupt installations Message-ID: <200010092337.QAA01073@bush.i.sourceforge.net> Patch #101844 has been updated. Project: Category: distutils Status: Open Summary: bdist_wininst creates corrupt installations Follow-Ups: Date: 2000-Oct-09 11:13 By: theller Comment: [Martin von Loewis] > I've created a PyXML distribution with recent distutils (0.93 and > 1.0). When installing these distributions, the installer creates empty > files only, see > > http://download.sourceforge.net/pyxml/PyXML-0.6.0.win32.exe > > for an example. > > I've tracked this down to usage of the zipfile module. If it does not > find an external zip program (which I did not have), it then tries to > use the zipfile module. Somehow, the installation program later cannot > process the files created with that module. > > The problem is probably in the installer, since Winzip 7 is capable of > reading the package, and extracts the files properly. > > I have solved the problem by installing infozip on my > machine. However, I'd appreciate if somebody could look into the > problem and let me know what the cause is. If you cannot reproduce the > problem, please let me know as well. > The problem was that the windows installer was using zipfile datastructures which are not always set. The following patch fixes this problem. Since currently I cannot check in these changes, I'm posting them here so they do not get lost. Note that wininst.exe must be recompiled and bdist_wininst.py must be regenerated to complete the fix. Thomas ------------------------------------------------------- Date: 2000-Oct-09 12:28 By: gvanrossum Comment: Hopefully Greg Ward will eb back to review this before 2.0 *final* goes out on Oct 16. ------------------------------------------------------- Date: 2000-Oct-09 12:54 By: akuchling Comment: Greg is supposed to be getting back around Friday the 13th. (Hmmm...) So the schedule will be tight, but I don't think Greg can do much checking on the Windows install; since the patch is from Thomas, he'll probably just trust it. ------------------------------------------------------- Date: 2000-Oct-09 13:44 By: jhylton Comment: Thomas, I have no idea how to apply this patch. I can't find the files mentioned anywhere in the Python CVS tree. ------------------------------------------------------- Date: 2000-Oct-09 13:58 By: jhylton Comment: AMK points out that this is a patch against some distutils source tree stored elsewhere. The code it patches is included as a base64 encoded string in the Python code. Wow! The sheer vulgarity of this impresses me. I think we should integrate the actual source code into the CVS tree when Greg gets back. ------------------------------------------------------- Date: 2000-Oct-09 16:37 By: loewis Comment: Please note that the patch fixes a problem that *only* occurs if you are using the bdist_wininst command of distutils (i.e. if you are the owner of a package and you want to produce Windows installers), and only if you do not have an external zip.exe. I feel users of Python 2.0 could live with this bug, if it was documented that they either need infozip or distutils 1.1 (which hopefully will contain the fix as well). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101844&group_id=5470 From noreply@sourceforge.net Tue Oct 10 04:34:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 9 Oct 2000 20:34:57 -0700 Subject: [Patches] [Patch #101850] Documentation for SAX2 Message-ID: <200010100334.UAA09621@bush.i.sourceforge.net> Patch #101850 has been updated. Project: Category: documentation Status: Open Summary: Documentation for SAX2 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101850&group_id=5470 From noreply@sourceforge.net Tue Oct 10 14:14:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Oct 2000 06:14:33 -0700 Subject: [Patches] [Patch #101844] bdist_wininst creates corrupt installations Message-ID: <200010101314.GAA25535@delerium.i.sourceforge.net> Patch #101844 has been updated. Project: Category: distutils Status: Open Summary: bdist_wininst creates corrupt installations Follow-Ups: Date: 2000-Oct-09 11:13 By: theller Comment: [Martin von Loewis] > I've created a PyXML distribution with recent distutils (0.93 and > 1.0). When installing these distributions, the installer creates empty > files only, see > > http://download.sourceforge.net/pyxml/PyXML-0.6.0.win32.exe > > for an example. > > I've tracked this down to usage of the zipfile module. If it does not > find an external zip program (which I did not have), it then tries to > use the zipfile module. Somehow, the installation program later cannot > process the files created with that module. > > The problem is probably in the installer, since Winzip 7 is capable of > reading the package, and extracts the files properly. > > I have solved the problem by installing infozip on my > machine. However, I'd appreciate if somebody could look into the > problem and let me know what the cause is. If you cannot reproduce the > problem, please let me know as well. > The problem was that the windows installer was using zipfile datastructures which are not always set. The following patch fixes this problem. Since currently I cannot check in these changes, I'm posting them here so they do not get lost. Note that wininst.exe must be recompiled and bdist_wininst.py must be regenerated to complete the fix. Thomas ------------------------------------------------------- Date: 2000-Oct-09 12:28 By: gvanrossum Comment: Hopefully Greg Ward will eb back to review this before 2.0 *final* goes out on Oct 16. ------------------------------------------------------- Date: 2000-Oct-09 12:54 By: akuchling Comment: Greg is supposed to be getting back around Friday the 13th. (Hmmm...) So the schedule will be tight, but I don't think Greg can do much checking on the Windows install; since the patch is from Thomas, he'll probably just trust it. ------------------------------------------------------- Date: 2000-Oct-09 13:44 By: jhylton Comment: Thomas, I have no idea how to apply this patch. I can't find the files mentioned anywhere in the Python CVS tree. ------------------------------------------------------- Date: 2000-Oct-09 13:58 By: jhylton Comment: AMK points out that this is a patch against some distutils source tree stored elsewhere. The code it patches is included as a base64 encoded string in the Python code. Wow! The sheer vulgarity of this impresses me. I think we should integrate the actual source code into the CVS tree when Greg gets back. ------------------------------------------------------- Date: 2000-Oct-09 16:37 By: loewis Comment: Please note that the patch fixes a problem that *only* occurs if you are using the bdist_wininst command of distutils (i.e. if you are the owner of a package and you want to produce Windows installers), and only if you do not have an external zip.exe. I feel users of Python 2.0 could live with this bug, if it was documented that they either need infozip or distutils 1.1 (which hopefully will contain the fix as well). ------------------------------------------------------- Date: 2000-Oct-10 06:14 By: theller Comment: Please see the comments I posted to python-dev: http://www.python.org/pipermail/python-dev/2000-October/016540.html ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101844&group_id=5470 From noreply@sourceforge.net Tue Oct 10 17:25:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Oct 2000 09:25:57 -0700 Subject: [Patches] [Patch #101857] ifdef for USE_STACKCHECK consistant Message-ID: <200010101625.JAA06886@bush.i.sourceforge.net> Patch #101857 has been updated. Project: Category: core (C code) Status: Open Summary: ifdef for USE_STACKCHECK consistant ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101857&group_id=5470 From noreply@sourceforge.net Tue Oct 10 19:39:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Oct 2000 11:39:52 -0700 Subject: [Patches] [Patch #101859] copy_reg: raise TypeError used with class objects Message-ID: <200010101839.LAA12437@bush.i.sourceforge.net> Patch #101859 has been updated. Project: Category: library Status: Open Summary: copy_reg: raise TypeError used with class objects ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101859&group_id=5470 From noreply@sourceforge.net Tue Oct 10 19:43:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Oct 2000 11:43:15 -0700 Subject: [Patches] [Patch #101859] copy_reg: raise TypeError used with class objects Message-ID: <200010101843.LAA12613@bush.i.sourceforge.net> Patch #101859 has been updated. Project: Category: library Status: Open Summary: copy_reg: raise TypeError used with class objects Follow-Ups: Date: 2000-Oct-10 11:43 By: fdrake Comment: This patch adds some clarification to the module docstring and adds a test inside the coy_reg.pickle() function that causes it to raise TypeError with a useful message when a class is passed as the type. This would have avoided the problem reported in bug #116295. Assigned to Jeremy for approval since the release candidate has already gone out. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101859&group_id=5470 From noreply@sourceforge.net Tue Oct 10 20:26:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Oct 2000 12:26:33 -0700 Subject: [Patches] [Patch #101859] copy_reg: raise TypeError used with class objects Message-ID: <200010101926.MAA14485@bush.i.sourceforge.net> Patch #101859 has been updated. Project: Category: library Status: Open Summary: copy_reg: raise TypeError used with class objects Follow-Ups: Date: 2000-Oct-10 11:43 By: fdrake Comment: This patch adds some clarification to the module docstring and adds a test inside the coy_reg.pickle() function that causes it to raise TypeError with a useful message when a class is passed as the type. This would have avoided the problem reported in bug #116295. Assigned to Jeremy for approval since the release candidate has already gone out. ------------------------------------------------------- Date: 2000-Oct-10 12:26 By: fdrake Comment: Added tests that the reduction function and constructor are actually callable, and test cases to make sure TypeError is raised in each case when the types are inappropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101859&group_id=5470 From noreply@sourceforge.net Tue Oct 10 22:08:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Oct 2000 14:08:09 -0700 Subject: [Patches] [Patch #101862] test_fcntl.py needs "Darwin1.2" added among the BSD's Message-ID: <200010102108.OAA12738@delerium.i.sourceforge.net> Patch #101862 has been updated. Project: Category: Modules Status: Open Summary: test_fcntl.py needs "Darwin1.2" added among the BSD's ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101862&group_id=5470 From noreply@sourceforge.net Wed Oct 11 04:14:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Oct 2000 20:14:56 -0700 Subject: [Patches] [Patch #101862] test_fcntl.py needs "Darwin1.2" added among the BSD's Message-ID: <200010110314.UAA26452@delerium.i.sourceforge.net> Patch #101862 has been updated. Project: Category: Modules Status: Open Summary: test_fcntl.py needs "Darwin1.2" added among the BSD's ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101862&group_id=5470 From noreply@sourceforge.net Wed Oct 11 05:26:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Oct 2000 21:26:37 -0700 Subject: [Patches] [Patch #101857] ifdef for USE_STACKCHECK consistant Message-ID: <200010110426.VAA28891@delerium.i.sourceforge.net> Patch #101857 has been updated. Project: Category: core (C code) Status: Rejected Summary: ifdef for USE_STACKCHECK consistant Follow-Ups: Date: 2000-Oct-10 21:26 By: fdrake Comment: Did you do an extensive check for other instances of this syntax? There are a *lot* of instances of this: $ grep '^#if defined([a-zA-Z0-9_]*)$' */*.[ch] | wc -l 70 This patch only changes the result by two. I'm rejecting this on the basis that it isn't important and doesn't impose any measure of consistency. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101857&group_id=5470 From dkwolfe@pacbell.net Wed Oct 11 07:13:55 2000 From: dkwolfe@pacbell.net (Dan Wolfe) Date: Tue, 10 Oct 2000 23:13:55 -0700 Subject: [Patches] Re: [Patch #101857] ifdef for USE_STACKCHECK consistant Message-ID: <0G290054859F6N@mta5.snfc21.pbi.net> >Patch #101857 has been updated. > actually no, I didn't do a check for all "#if defined"'s as I was looking only for the USE_STACKCHECK variable to figure out how to fix another bug.... Ok... I'll hold off doing a grep and a patch against the entire source until after 2.0 ships... : -) Thanks for pointing out that I overlooked all the other #if defined's - Dan >Project: >Category: core (C code) >Status: Rejected >Summary: ifdef for USE_STACKCHECK consistant > >Follow-Ups: > >Date: 2000-Oct-10 21:26 >By: fdrake > >Comment: >Did you do an extensive check for other instances of this syntax? There >are a *lot* of instances of this: > >$ grep '^#if defined([a-zA-Z0-9_]*)$' */*.[ch] | wc -l > 70 > >This patch only changes the result by two. >I'm rejecting this on the basis that it isn't important and doesn't impose >any measure of consistency. >------------------------------------------------------- > >------------------------------------------------------- >For more info, visit: > >http://sourceforge.net/patch/?func=detailpatch&patch_id=101857&group_id=5470 From noreply@sourceforge.net Wed Oct 11 15:26:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Oct 2000 07:26:57 -0700 Subject: [Patches] [Patch #101810] Fix MemoryError when decompressing empty string Message-ID: <200010111426.HAA24896@bush.i.sourceforge.net> Patch #101810 has been updated. Project: Category: Modules Status: Closed Summary: Fix MemoryError when decompressing empty string Follow-Ups: Date: 2000-Oct-06 13:07 By: jhylton Comment: Change this: if (0 < zst.avail_out) to this: if (zst.avail_out > 0) and it's fine. Do you want to check it in or should I? ------------------------------------------------------- Date: 2000-Oct-06 13:15 By: akuchling Comment: One final reservation: the zlib library's API is poorly defined. As I interpret the docs quoted in the DejaNews posting, this change is correct. It might break with old versions of the zlib library. On the other hand, the current version has been 1.1.3 since 1998. I'd suggest checking in the patch, but if you want to be conservative, let me know. If I get a go-ahead in the next hour or so, I'll be around to check it in. ------------------------------------------------------- Date: 2000-Oct-11 07:26 By: gvanrossum Comment: Checked in by Andrew as 2.36. Please don't forget to close patches when applied! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101810&group_id=5470 From noreply@sourceforge.net Wed Oct 11 23:15:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Oct 2000 15:15:19 -0700 Subject: [Patches] [Patch #101870] Make XMLFilterBase usable Message-ID: <200010112215.PAA05234@delerium.i.sourceforge.net> Patch #101870 has been updated. Project: Category: XML Status: Open Summary: Make XMLFilterBase usable ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101870&group_id=5470 From noreply@sourceforge.net Wed Oct 11 23:18:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Oct 2000 15:18:25 -0700 Subject: [Patches] [Patch #101859] copy_reg: raise TypeError used with class objects Message-ID: <200010112218.PAA11882@bush.i.sourceforge.net> Patch #101859 has been updated. Project: Category: library Status: Closed Summary: copy_reg: raise TypeError used with class objects Follow-Ups: Date: 2000-Oct-10 11:43 By: fdrake Comment: This patch adds some clarification to the module docstring and adds a test inside the coy_reg.pickle() function that causes it to raise TypeError with a useful message when a class is passed as the type. This would have avoided the problem reported in bug #116295. Assigned to Jeremy for approval since the release candidate has already gone out. ------------------------------------------------------- Date: 2000-Oct-10 12:26 By: fdrake Comment: Added tests that the reduction function and constructor are actually callable, and test cases to make sure TypeError is raised in each case when the types are inappropriate. ------------------------------------------------------- Date: 2000-Oct-11 15:18 By: fdrake Comment: Checked in as Lib/copy_reg.py revision 1.4, and new test & test output files. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101859&group_id=5470 From noreply@sourceforge.net Wed Oct 11 23:26:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Oct 2000 15:26:37 -0700 Subject: [Patches] [Patch #101870] Make XMLFilterBase usable Message-ID: <200010112226.PAA12129@bush.i.sourceforge.net> Patch #101870 has been updated. Project: Category: XML Status: Accepted Summary: Make XMLFilterBase usable ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101870&group_id=5470 From noreply@sourceforge.net Wed Oct 11 23:40:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Oct 2000 15:40:55 -0700 Subject: [Patches] [Patch #101870] Make XMLFilterBase usable Message-ID: <200010112240.PAA06230@delerium.i.sourceforge.net> Patch #101870 has been updated. Project: Category: XML Status: Closed Summary: Make XMLFilterBase usable ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101870&group_id=5470 From noreply@sourceforge.net Thu Oct 12 17:03:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Oct 2000 09:03:01 -0700 Subject: [Patches] [Patch #101862] test_fcntl.py needs "Darwin1.2" added among the BSD's Message-ID: <200010121603.JAA11947@delerium.i.sourceforge.net> Patch #101862 has been updated. Project: Category: Modules Status: Closed Summary: test_fcntl.py needs "Darwin1.2" added among the BSD's Follow-Ups: Date: 2000-Oct-12 09:03 By: gvanrossum Comment: OK, checked in, since it seems harmless. (Why isn't it 'darwin1' like the convention seems to be?) Someone on Darwin please test this! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101862&group_id=5470 From noreply@sourceforge.net Thu Oct 12 18:31:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Oct 2000 10:31:59 -0700 Subject: [Patches] [Patch #101850] Documentation for SAX2 Message-ID: <200010121731.KAA21609@bush.i.sourceforge.net> Patch #101850 has been updated. Project: Category: documentation Status: Open Summary: Documentation for SAX2 Follow-Ups: Date: 2000-Oct-12 10:31 By: fdrake Comment: Working on this one now... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101850&group_id=5470 From noreply@sourceforge.net Thu Oct 12 19:14:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Oct 2000 11:14:23 -0700 Subject: [Patches] [Patch #101877] Completed codecs API docs Message-ID: <200010121814.LAA17235@delerium.i.sourceforge.net> Patch #101877 has been updated. Project: Category: documentation Status: Open Summary: Completed codecs API docs ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101877&group_id=5470 From noreply@sourceforge.net Thu Oct 12 19:16:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Oct 2000 11:16:45 -0700 Subject: [Patches] [Patch #101877] Completed codecs API docs Message-ID: <200010121816.LAA17405@delerium.i.sourceforge.net> Patch #101877 has been updated. Project: Category: documentation Status: Open Summary: Completed codecs API docs Follow-Ups: Date: 2000-Oct-12 11:16 By: lemburg Comment: This is not a patch but the whole file. It basically includes the TeXified docs strings of the codecs.py module with some extra comments here and there. Please review and test (I don't have a running TeX environment) and then close the bug # 115308 ] codecs base classes need documentation Thanks. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101877&group_id=5470 From noreply@sourceforge.net Thu Oct 12 19:56:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Oct 2000 11:56:15 -0700 Subject: [Patches] [Patch #101880] Make unlink clean up siblings Message-ID: <200010121856.LAA18939@delerium.i.sourceforge.net> Patch #101880 has been updated. Project: Category: XML Status: Open Summary: Make unlink clean up siblings ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101880&group_id=5470 From noreply@sourceforge.net Thu Oct 12 20:43:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Oct 2000 12:43:54 -0700 Subject: [Patches] [Patch #101882] Minor pth support cleanup Message-ID: <200010121943.MAA20717@delerium.i.sourceforge.net> Patch #101882 has been updated. Project: Category: core (C code) Status: Open Summary: Minor pth support cleanup ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101882&group_id=5470 From noreply@sourceforge.net Thu Oct 12 20:45:26 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Oct 2000 12:45:26 -0700 Subject: [Patches] [Patch #101882] Minor pth support cleanup Message-ID: <200010121945.MAA20837@delerium.i.sourceforge.net> Patch #101882 has been updated. Project: Category: core (C code) Status: Open Summary: Minor pth support cleanup Follow-Ups: Date: 2000-Oct-12 12:45 By: adustman Comment: Eliminate unused variables to appease compiler. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101882&group_id=5470 From noreply@sourceforge.net Thu Oct 12 20:45:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Oct 2000 12:45:25 -0700 Subject: [Patches] [Patch #101882] Minor pth support cleanup Message-ID: <200010121945.MAA20830@delerium.i.sourceforge.net> Patch #101882 has been updated. Project: Category: core (C code) Status: Open Summary: Minor pth support cleanup Follow-Ups: Date: 2000-Oct-12 12:45 By: adustman Comment: Eliminate unused variables to appease compiler. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101882&group_id=5470 From noreply@sourceforge.net Thu Oct 12 20:46:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Oct 2000 12:46:06 -0700 Subject: [Patches] [Patch #101844] bdist_wininst creates corrupt installations Message-ID: <200010121946.MAA26937@bush.i.sourceforge.net> Patch #101844 has been updated. Project: Category: distutils Status: Closed Summary: bdist_wininst creates corrupt installations Follow-Ups: Date: 2000-Oct-09 11:13 By: theller Comment: [Martin von Loewis] > I've created a PyXML distribution with recent distutils (0.93 and > 1.0). When installing these distributions, the installer creates empty > files only, see > > http://download.sourceforge.net/pyxml/PyXML-0.6.0.win32.exe > > for an example. > > I've tracked this down to usage of the zipfile module. If it does not > find an external zip program (which I did not have), it then tries to > use the zipfile module. Somehow, the installation program later cannot > process the files created with that module. > > The problem is probably in the installer, since Winzip 7 is capable of > reading the package, and extracts the files properly. > > I have solved the problem by installing infozip on my > machine. However, I'd appreciate if somebody could look into the > problem and let me know what the cause is. If you cannot reproduce the > problem, please let me know as well. > The problem was that the windows installer was using zipfile datastructures which are not always set. The following patch fixes this problem. Since currently I cannot check in these changes, I'm posting them here so they do not get lost. Note that wininst.exe must be recompiled and bdist_wininst.py must be regenerated to complete the fix. Thomas ------------------------------------------------------- Date: 2000-Oct-09 12:28 By: gvanrossum Comment: Hopefully Greg Ward will eb back to review this before 2.0 *final* goes out on Oct 16. ------------------------------------------------------- Date: 2000-Oct-09 12:54 By: akuchling Comment: Greg is supposed to be getting back around Friday the 13th. (Hmmm...) So the schedule will be tight, but I don't think Greg can do much checking on the Windows install; since the patch is from Thomas, he'll probably just trust it. ------------------------------------------------------- Date: 2000-Oct-09 13:44 By: jhylton Comment: Thomas, I have no idea how to apply this patch. I can't find the files mentioned anywhere in the Python CVS tree. ------------------------------------------------------- Date: 2000-Oct-09 13:58 By: jhylton Comment: AMK points out that this is a patch against some distutils source tree stored elsewhere. The code it patches is included as a base64 encoded string in the Python code. Wow! The sheer vulgarity of this impresses me. I think we should integrate the actual source code into the CVS tree when Greg gets back. ------------------------------------------------------- Date: 2000-Oct-09 16:37 By: loewis Comment: Please note that the patch fixes a problem that *only* occurs if you are using the bdist_wininst command of distutils (i.e. if you are the owner of a package and you want to produce Windows installers), and only if you do not have an external zip.exe. I feel users of Python 2.0 could live with this bug, if it was documented that they either need infozip or distutils 1.1 (which hopefully will contain the fix as well). ------------------------------------------------------- Date: 2000-Oct-10 06:14 By: theller Comment: Please see the comments I posted to python-dev: http://www.python.org/pipermail/python-dev/2000-October/016540.html ------------------------------------------------------- Date: 2000-Oct-12 12:46 By: theller Comment: Reassigned to me and closed because I have fixed it. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101844&group_id=5470 From noreply@sourceforge.net Thu Oct 12 21:13:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Oct 2000 13:13:00 -0700 Subject: [Patches] [Patch #101850] Documentation for SAX2 Message-ID: <200010122013.NAA21854@delerium.i.sourceforge.net> Patch #101850 has been updated. Project: Category: documentation Status: Closed Summary: Documentation for SAX2 Follow-Ups: Date: 2000-Oct-12 10:31 By: fdrake Comment: Working on this one now... ------------------------------------------------------- Date: 2000-Oct-12 13:13 By: fdrake Comment: Checked in with significant re-arrangement but little content change as Doc/lib/xmlsax.tex revision 1.2, and new files xmlsaxhandler.tex, xmlsaxutils.tex, and xmlsaxreader.tex, all in the Doc/lib/ directory. Thanks, Martin! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101850&group_id=5470 From noreply@sourceforge.net Thu Oct 12 21:23:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Oct 2000 13:23:12 -0700 Subject: [Patches] [Patch #101880] Make unlink clean up siblings Message-ID: <200010122023.NAA22250@delerium.i.sourceforge.net> Patch #101880 has been updated. Project: Category: XML Status: Accepted Summary: Make unlink clean up siblings Follow-Ups: Date: 2000-Oct-12 13:23 By: fdrake Comment: Please check this in if this is still needed once you & Lars are happy with your decisions. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101880&group_id=5470 From noreply@sourceforge.net Thu Oct 12 21:51:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Oct 2000 13:51:58 -0700 Subject: [Patches] [Patch #101877] Completed codecs API docs Message-ID: <200010122051.NAA23431@delerium.i.sourceforge.net> Patch #101877 has been updated. Project: Category: documentation Status: Closed Summary: Completed codecs API docs Follow-Ups: Date: 2000-Oct-12 11:16 By: lemburg Comment: This is not a patch but the whole file. It basically includes the TeXified docs strings of the codecs.py module with some extra comments here and there. Please review and test (I don't have a running TeX environment) and then close the bug # 115308 ] codecs base classes need documentation Thanks. ------------------------------------------------------- Date: 2000-Oct-12 13:51 By: fdrake Comment: Checked in with substantial markup changes as Doc/lib/libcodecs.tex revision 1.4. Closing related bug #115308. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101877&group_id=5470 From noreply@sourceforge.net Thu Oct 12 21:59:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Oct 2000 13:59:18 -0700 Subject: [Patches] [Patch #101882] Minor pth support cleanup Message-ID: <200010122059.NAA23676@delerium.i.sourceforge.net> Patch #101882 has been updated. Project: Category: core (C code) Status: Closed Summary: Minor pth support cleanup Follow-Ups: Date: 2000-Oct-12 12:45 By: adustman Comment: Eliminate unused variables to appease compiler. ------------------------------------------------------- Date: 2000-Oct-12 13:59 By: fdrake Comment: Checked in as Python/thread_pth.h revision 2.7. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101882&group_id=5470 From noreply@sourceforge.net Fri Oct 13 20:59:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Oct 2000 12:59:31 -0700 Subject: [Patches] [Patch #101896] fix to expatreader incremental parsing Message-ID: <200010131959.MAA19910@delerium.i.sourceforge.net> Patch #101896 has been updated. Project: Category: XML Status: Open Summary: fix to expatreader incremental parsing ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101896&group_id=5470 From noreply@sourceforge.net Fri Oct 13 21:00:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Oct 2000 13:00:25 -0700 Subject: [Patches] [Patch #101896] fix to expatreader incremental parsing Message-ID: <200010132000.NAA19959@delerium.i.sourceforge.net> Patch #101896 has been updated. Project: Category: XML Status: Open Summary: fix to expatreader incremental parsing Follow-Ups: Date: 2000-Oct-13 13:00 By: larsga Comment: Without this, the sequence below will lack a startDocument() call in the second parse. parser = make_parser() parser.parse("file.xml") parser.reset() parser.feed("") parser.close() ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101896&group_id=5470 From noreply@sourceforge.net Fri Oct 13 21:05:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Oct 2000 13:05:32 -0700 Subject: [Patches] [Patch #101897] make dom.unlink() remove sibling cycles Message-ID: <200010132005.NAA20151@delerium.i.sourceforge.net> Patch #101897 has been updated. Project: Category: XML Status: Open Summary: make dom.unlink() remove sibling cycles ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101897&group_id=5470 From noreply@sourceforge.net Fri Oct 13 21:14:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Oct 2000 13:14:05 -0700 Subject: [Patches] [Patch #101897] make dom.unlink() remove sibling cycles Message-ID: <200010132014.NAA20522@delerium.i.sourceforge.net> Patch #101897 has been updated. Project: Category: XML Status: Deleted Summary: make dom.unlink() remove sibling cycles ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101897&group_id=5470 From noreply@sourceforge.net Sat Oct 14 02:54:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Oct 2000 18:54:58 -0700 Subject: [Patches] [Patch #101896] fix to expatreader incremental parsing Message-ID: <200010140154.SAA00774@delerium.i.sourceforge.net> Patch #101896 has been updated. Project: Category: XML Status: Accepted Summary: fix to expatreader incremental parsing Follow-Ups: Date: 2000-Oct-13 13:00 By: larsga Comment: Without this, the sequence below will lack a startDocument() call in the second parse. parser = make_parser() parser.parse("file.xml") parser.reset() parser.feed("") parser.close() ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101896&group_id=5470 From noreply@sourceforge.net Sat Oct 14 07:06:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Oct 2000 23:06:25 -0700 Subject: [Patches] [Patch #101904] Better SWIG with C++ support Message-ID: <200010140606.XAA09373@delerium.i.sourceforge.net> Patch #101904 has been updated. Project: Category: distutils Status: Open Summary: Better SWIG with C++ support ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101904&group_id=5470 From noreply@sourceforge.net Sat Oct 14 07:07:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Oct 2000 23:07:32 -0700 Subject: [Patches] [Patch #101904] Better SWIG with C++ support Message-ID: <200010140607.XAA09397@delerium.i.sourceforge.net> Patch #101904 has been updated. Project: Category: distutils Status: Open Summary: Better SWIG with C++ support Follow-Ups: Date: 2000-Oct-13 23:07 By: jgbauman Comment: I had troubles with distutils 1.0 and the way I use SWIG. I couldn't find any support for the -shadow option and no way to pass an extra include dir to swig (like it´s possible for the c compiler) Therefore I wrote a patch. It adds an extra_swig_args (list of string) option to Extension. All the strings are passed to swig without modification, but if extra_swig_args contains "-c++" or "-shadow" there is some special action: "-c++": behaves like build_ext --swig-cpp "-shadow": Normally swig generates a file: foo.c -> foo.so In this case SWIG generates two files: foo.py (python shadow classes, imports fooc) fooc.c -> fooc.so With this patch build_ext can handle this und generates for foo.i (foo.py, fooc.c) compiles them and installs them. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101904&group_id=5470 From noreply@sourceforge.net Sat Oct 14 07:07:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Oct 2000 23:07:31 -0700 Subject: [Patches] [Patch #101904] Better SWIG with C++ support Message-ID: <200010140607.XAA09393@delerium.i.sourceforge.net> Patch #101904 has been updated. Project: Category: distutils Status: Open Summary: Better SWIG with C++ support Follow-Ups: Date: 2000-Oct-13 23:07 By: jgbauman Comment: I had troubles with distutils 1.0 and the way I use SWIG. I couldn't find any support for the -shadow option and no way to pass an extra include dir to swig (like it´s possible for the c compiler) Therefore I wrote a patch. It adds an extra_swig_args (list of string) option to Extension. All the strings are passed to swig without modification, but if extra_swig_args contains "-c++" or "-shadow" there is some special action: "-c++": behaves like build_ext --swig-cpp "-shadow": Normally swig generates a file: foo.c -> foo.so In this case SWIG generates two files: foo.py (python shadow classes, imports fooc) fooc.c -> fooc.so With this patch build_ext can handle this und generates for foo.i (foo.py, fooc.c) compiles them and installs them. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101904&group_id=5470 From noreply@sourceforge.net Sat Oct 14 11:23:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Oct 2000 03:23:35 -0700 Subject: [Patches] [Patch #101880] Make unlink clean up siblings Message-ID: <200010141023.DAA17503@delerium.i.sourceforge.net> Patch #101880 has been updated. Project: Category: XML Status: Closed Summary: Make unlink clean up siblings Follow-Ups: Date: 2000-Oct-12 13:23 By: fdrake Comment: Please check this in if this is still needed once you & Lars are happy with your decisions. ------------------------------------------------------- Date: 2000-Oct-14 03:23 By: larsga Comment: Paul has checked this in already (revision 1.12). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101880&group_id=5470 From noreply@sourceforge.net Sat Oct 14 11:28:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Oct 2000 03:28:17 -0700 Subject: [Patches] [Patch #101896] fix to expatreader incremental parsing Message-ID: <200010141028.DAA17658@delerium.i.sourceforge.net> Patch #101896 has been updated. Project: Category: XML Status: Closed Summary: fix to expatreader incremental parsing Follow-Ups: Date: 2000-Oct-13 13:00 By: larsga Comment: Without this, the sequence below will lack a startDocument() call in the second parse. parser = make_parser() parser.parse("file.xml") parser.reset() parser.feed("") parser.close() ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101896&group_id=5470 From noreply@sourceforge.net Mon Oct 16 08:11:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Oct 2000 00:11:03 -0700 Subject: [Patches] [Patch #101928] gettext fails to find .mo file (Bug #116964) Message-ID: <200010160711.AAA12982@bush.i.sourceforge.net> Patch #101928 has been updated. Project: Category: library Status: Open Summary: gettext fails to find .mo file (Bug #116964) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101928&group_id=5470 From noreply@sourceforge.net Mon Oct 16 15:10:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Oct 2000 07:10:53 -0700 Subject: [Patches] [Patch #101928] gettext fails to find .mo file (Bug #116964) Message-ID: <200010161410.HAA32262@delerium.i.sourceforge.net> Patch #101928 has been updated. Project: Category: library Status: Open Summary: gettext fails to find .mo file (Bug #116964) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101928&group_id=5470 From noreply@sourceforge.net Mon Oct 16 15:11:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Oct 2000 07:11:40 -0700 Subject: [Patches] [Patch #101904] Better SWIG with C++ support Message-ID: <200010161411.HAA32276@delerium.i.sourceforge.net> Patch #101904 has been updated. Project: Category: distutils Status: Open Summary: Better SWIG with C++ support Follow-Ups: Date: 2000-Oct-13 23:07 By: jgbauman Comment: I had troubles with distutils 1.0 and the way I use SWIG. I couldn't find any support for the -shadow option and no way to pass an extra include dir to swig (like it´s possible for the c compiler) Therefore I wrote a patch. It adds an extra_swig_args (list of string) option to Extension. All the strings are passed to swig without modification, but if extra_swig_args contains "-c++" or "-shadow" there is some special action: "-c++": behaves like build_ext --swig-cpp "-shadow": Normally swig generates a file: foo.c -> foo.so In this case SWIG generates two files: foo.py (python shadow classes, imports fooc) fooc.c -> fooc.so With this patch build_ext can handle this und generates for foo.i (foo.py, fooc.c) compiles them and installs them. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101904&group_id=5470 From noreply@sourceforge.net Mon Oct 16 16:42:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Oct 2000 08:42:50 -0700 Subject: [Patches] [Patch #101928] gettext fails to find .mo file (Bug #116964) Message-ID: <200010161542.IAA03596@delerium.i.sourceforge.net> Patch #101928 has been updated. Project: Category: library Status: Closed Summary: gettext fails to find .mo file (Bug #116964) Follow-Ups: Date: 2000-Oct-16 08:42 By: bwarsaw Comment: Applied to Lib/gettext.py revision 1.9 (made it into Python 2.0 final). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101928&group_id=5470 From noreply@sourceforge.net Mon Oct 16 17:36:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Oct 2000 09:36:59 -0700 Subject: [Patches] [Patch #101936] Auto-detect DEC threads (which need "-threads" argument) Message-ID: <200010161636.JAA05856@delerium.i.sourceforge.net> Patch #101936 has been updated. Project: Category: Build Status: Open Summary: Auto-detect DEC threads (which need "-threads" argument) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101936&group_id=5470 From noreply@sourceforge.net Mon Oct 16 17:38:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Oct 2000 09:38:48 -0700 Subject: [Patches] [Patch #101936] Auto-detect DEC threads (which need "-threads" argument) Message-ID: <200010161638.JAA05997@delerium.i.sourceforge.net> Patch #101936 has been updated. Project: Category: Build Status: Open Summary: Auto-detect DEC threads (which need "-threads" argument) Follow-Ups: Date: 2000-Oct-16 09:38 By: twouters Comment: As discussed on python-dev. Assigned to Jeremy so it won't be forgotten. I'm not sure when the release is going to happen, but I'm going to be incommunicado for a while and I wouldn't want this patch to be lost because of that. Don't forget to rerun 'autoconf' after applying. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101936&group_id=5470 From noreply@sourceforge.net Mon Oct 16 17:59:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Oct 2000 09:59:31 -0700 Subject: [Patches] [Patch #101936] Auto-detect DEC threads (which need "-threads" argument) Message-ID: <200010161659.JAA03353@bush.i.sourceforge.net> Patch #101936 has been updated. Project: Category: Build Status: Closed Summary: Auto-detect DEC threads (which need "-threads" argument) Follow-Ups: Date: 2000-Oct-16 09:38 By: twouters Comment: As discussed on python-dev. Assigned to Jeremy so it won't be forgotten. I'm not sure when the release is going to happen, but I'm going to be incommunicado for a while and I wouldn't want this patch to be lost because of that. Don't forget to rerun 'autoconf' after applying. ------------------------------------------------------- Date: 2000-Oct-16 09:59 By: jhylton Comment: added in rev. 1.173 of configure.in and corresponding configure ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101936&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:21 -0700 Subject: [Patches] [Patch #101485] Patch to test sendmail virtual domain gid's for bug #114235 Message-ID: <200010181444.HAA14039@delerium.i.sourceforge.net> Patch #101485 has been updated. Project: Category: None Status: Open Summary: Patch to test sendmail virtual domain gid's for bug #114235 Follow-Ups: Date: 2000-Sep-12 15:22 By: bwarsaw Comment: See SF bug #114235 for what this program tests. This patch (and the bug) really have nothing to do with Python, I believe. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101485&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:25 -0700 Subject: [Patches] [Patch #101664] Add new unistr() builtin + PyObject_Unicode() C API Message-ID: <200010181444.HAA14068@delerium.i.sourceforge.net> Patch #101664 has been updated. Project: Category: core (C code) Status: Open Summary: Add new unistr() builtin + PyObject_Unicode() C API Follow-Ups: Date: 2000-Sep-26 04:14 By: lemburg Comment: This patch adds a utility function unistr() which works just like the standard builtin str() -- only that the return value will always be a Unicode object. The patch also adds a new object level C API PyObject_Unicode() which complements PyObject_Str(). Since this is a new feature, I have postponed the patch to be reopened in the 2.1 cycle. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101664&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:16 -0700 Subject: [Patches] [Patch #101250] Use '*args' instead of providing defaults in User*.py Message-ID: <200010181444.HAA14008@delerium.i.sourceforge.net> Patch #101250 has been updated. Project: Category: library Status: Open Summary: Use '*args' instead of providing defaults in User*.py Follow-Ups: Date: 2000-Aug-21 09:30 By: twouters Comment: Use the '*args' construct rather than providing function defaults that are passed on to the underlying datatype, in the UserList, UserDict and UserString modules. Note: UserString.encode() might like a **kwargs argument as well, I don't know how it's used. ------------------------------------------------------- Date: 2000-Aug-21 17:27 By: tim_one Comment: Postponed, unless you can justify why this should be considered a bugfix instead of a new feature. I confess I don't see the point even as a feature: the list etc interfaces are well-defined, and aren't *meant* to support arbitrary collections of signatures. Passing on arbitrary *args *will* have the effect of making tracebacks more confusing when things finally get down to the level where the concrete implementation finally gets a chance to complain about a goofy arglist. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101250&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:12 -0700 Subject: [Patches] [Patch #101104] Optional object mem allocator Message-ID: <200010181444.HAA13986@delerium.i.sourceforge.net> Patch #101104 has been updated. Project: Category: core (C code) Status: Open Summary: Optional object mem allocator Follow-Ups: Date: 2000-Aug-06 21:05 By: marangoz Comment: A stab on obmalloc.c -- an optional object allocator. A configure "--with(out)-pymalloc" option is introduced for enabling specialized mallocs. Off by default. The code is included conditionally at the end of object.c obmalloc.c contains only the core malloc functionality. No profiling, nor debugging are there -- these would come as separate (and optional) modules: memprof.c & memdebug.c in the Modules/ directory and will exploit the hooks of the allocator. I've managed to draw a rather nice diagram in the comments at the top of obmalloc.c explaining what this stuff is all about. Look there. ------------------------------------------------------- Date: 2000-Aug-07 06:30 By: twouters Comment: Small nit: you shouldn't edit config.h.in yourself, it's autogenerated from acconfig.h and configure.in (with 'autoheader', part of 'autoconf.) You should define WITH_PYMALLOC in acconfig.h, not config.h.in, and run 'autoheader' and 'autoconf' to generate a new 'configure'. I'm in the process of testing this patch on Linux and BSDI, by the way :) ------------------------------------------------------- Date: 2000-Aug-07 09:19 By: marangoz Comment: Thanks. Fixed (acconfig.h) ------------------------------------------------------- Date: 2000-Aug-12 13:31 By: marangoz Comment: Status set to Postponed. Although promising, this hasn't enjoyed much user testing for the 2.0 time frame (partly because of the lack of an introspective Python interface which can't be completed in time according to the release schedule). Assigned to marangoz who's responsible to reopen it again in due time (except if BDFL decides otherwise). ------------------------------------------------------- Date: 2000-Aug-18 21:11 By: marangoz Comment: Update: (1) fixing a missing case for realloc(p,0) == free(p) + ret NULL (2) simplify the hooks interface: set_hooks/fetch_hooks are better than install/uninstall. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101104&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:02 -0700 Subject: [Patches] [Patch #100899] a smaller unicode name database Message-ID: <200010181444.HAA13968@delerium.i.sourceforge.net> Patch #100899 has been updated. Project: Category: None Status: Open Summary: a smaller unicode name database Follow-Ups: Date: 2000-Jul-15 15:43 By: effbot Comment: duh. it's too large for sourceforge. if you want to play with it, get it from: http://w1.132.telia.com/~u13208596/uninames-patch.txt ------------------------------------------------------- Date: 2000-Aug-03 11:59 By: lemburg Comment: How is the work on this patch coming along ? Will it be ready for 2.0 ? ------------------------------------------------------- Date: 2000-Aug-15 10:42 By: tim_one Comment: /F or MAL, what's going on with this? MAL, did you look at the patch? /F, do you feel it's done? ------------------------------------------------------- Date: 2000-Aug-23 11:39 By: tim_one Comment: Assigned back to /F because he agrees the ball bounced back into his court: [/F, in Python-Dev mail] mal has reviewed the patch, and is waiting for an update from me. ------------------------------------------------------- Date: 2000-Aug-24 04:37 By: lemburg Comment: I'd rather see this patch postponed. Reason: We're not in a hury here -- better get this done right than to quickly throw together a set of patches without some more extensive testing. Comment for future reference: --------------------- Note that I would also like to unify the different Unicode databases (ctype DBs, Unicode DB and Unicode name DB) into one single unicodedb access module which will be written in Python. The sibling C modules can then be loaded dynamically and in a lazy fashion. This will result in an implementation which should be much easier to maintain than the current (2.0) setup. ------------------------------------------------------- Date: 2000-Aug-28 11:55 By: effbot Comment: postponed, for now. I'm still working on the full unidb package, and will reopen this patch again when I've fixed the other things that needs to be fixed before 2.0b1. ------------------------------------------------------- Date: 2000-Sep-23 21:10 By: tim_one Comment: Changed status to Postponed, to match the last thing that was said about it (a month ago). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100899&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:15 -0700 Subject: [Patches] [Patch #101229] Optional memory profiler Message-ID: <200010181444.HAA14004@delerium.i.sourceforge.net> Patch #101229 has been updated. Project: Category: core (C code) Status: Open Summary: Optional memory profiler Follow-Ups: Date: 2000-Aug-19 00:18 By: marangoz Comment: An optional memory profiler, which goes in tandem with the optional object memory allocator (SourceForge patch #101104). The profiler was introduced briefly on python-dev: http://www.python.org/pipermail/python-dev/2000-August/015239.html Applying both patches gives for me (screen dump): ~> patch -p1 < ../obmalloc-patch patching file `Include/objimpl.h' patching file `Objects/object.c' patching file `Objects/obmalloc.c' patching file `acconfig.h' patching file `configure.in' ~> patch -p1 < ../memprof-patch patching file `Include/pydebug.h' patching file `Modules/Setup.config.in' patching file `Modules/main.c' patching file `Modules/memprof.c' patching file `Python/pythonrun.c' patching file `acconfig.h' patching file `configure.in' - Don't forget that you need to autoheader; autoconf; This patch: 1) introduces a new --with-memprof configure option. Off by default. 2) introduced a Py_ProfileFlag and a "-p" Python option which starts the profiler in Py_Initialize() before any initializations, and stops it in Py_Finalize() after all finalizations. 3) contains a new Modules/memprof.c module. The inclusion of this file in the core is similar to the thread and GC modules (Setup.config.in) The patch *can* be applied without the object allocator and it *does* compile on request. However, it issues a warning that it won't profile anything, because it can't be called (the profiler can't install its hooks). Besides, it will refuse to start(). The point is that both the profiler and the allocator are really optional. Needs docs & tests :( The interface can be improved (just like everything else) but the core functionality is there. It *is* useful for getting snapshots of the minimum allocated (object) memory, at least. Some worthy points to condifer, IMO, are listed in the TODO of memprof.c. I am submitting this for testing, reviewing, comments and more ideas. Overall, I think it is a BIG plus regarding Python's typical introspection. Comments welcome. As usual, flames to /dev/null . Status set straight to Postponed. Assigned to marangoz who's in charge of opening it in due time, together with #101104. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101229&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:23 -0700 Subject: [Patches] [Patch #101647] adds SSL server socket support to socketmodule.c Message-ID: <200010181444.HAA14056@delerium.i.sourceforge.net> Patch #101647 has been updated. Project: Category: Modules Status: Open Summary: adds SSL server socket support to socketmodule.c Follow-Ups: Date: 2000-Sep-25 09:41 By: jhylton Comment: too late for 2.0 ------------------------------------------------------- Date: 2000-Sep-27 03:51 By: naris Comment: too late ? this patch solves world hunger and brings world peace! such a valuable patch, but i guess deadlines are deadlines :-( ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101647&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:23 -0700 Subject: [Patches] [Patch #101647] adds SSL server socket support to socketmodule.c Message-ID: <200010181444.HAA14057@delerium.i.sourceforge.net> Patch #101647 has been updated. Project: Category: Modules Status: Open Summary: adds SSL server socket support to socketmodule.c Follow-Ups: Date: 2000-Sep-25 09:41 By: jhylton Comment: too late for 2.0 ------------------------------------------------------- Date: 2000-Sep-27 03:51 By: naris Comment: too late ? this patch solves world hunger and brings world peace! such a valuable patch, but i guess deadlines are deadlines :-( ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101647&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:27 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:27 -0700 Subject: [Patches] [Patch #101842] Localization of calendar module. Message-ID: <200010181444.HAA14084@delerium.i.sourceforge.net> Patch #101842 has been updated. Project: Category: library Status: Open Summary: Localization of calendar module. Follow-Ups: Date: 2000-Oct-09 01:34 By: ods Comment: This work fine for all locales on NT, but may work a bit strange with some locales (e.g. ru_RU) on some platforms with buggy (IMHO) L10n of strftime (e.g. RedHat Linux). ------------------------------------------------------- Date: 2000-Oct-09 05:46 By: gvanrossum Comment: This seems a little too much code while we're in a feature freeze. Let's do this after 2.0final is released. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101842&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:27 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:27 -0700 Subject: [Patches] [Patch #101842] Localization of calendar module. Message-ID: <200010181444.HAA14083@delerium.i.sourceforge.net> Patch #101842 has been updated. Project: Category: library Status: Open Summary: Localization of calendar module. Follow-Ups: Date: 2000-Oct-09 01:34 By: ods Comment: This work fine for all locales on NT, but may work a bit strange with some locales (e.g. ru_RU) on some platforms with buggy (IMHO) L10n of strftime (e.g. RedHat Linux). ------------------------------------------------------- Date: 2000-Oct-09 05:46 By: gvanrossum Comment: This seems a little too much code while we're in a feature freeze. Let's do this after 2.0final is released. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101842&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:22 -0700 Subject: [Patches] [Patch #101606] threads and __del__ Message-ID: <200010181444.HAA14045@delerium.i.sourceforge.net> Patch #101606 has been updated. Project: Category: core (C code) Status: Open Summary: threads and __del__ Follow-Ups: Date: 2000-Sep-22 08:06 By: gvanrossum Comment: Works fine for me. Assigned to Tim for review since he's the race condition czar. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101606&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:19 -0700 Subject: [Patches] [Patch #101335] Adds login to auth-type servers Message-ID: <200010181444.HAA14020@delerium.i.sourceforge.net> Patch #101335 has been updated. Project: Category: library Status: Open Summary: Adds login to auth-type servers Follow-Ups: Date: 2000-Aug-29 02:22 By: moshez Comment: Postponed -- we're in feature freeze. Assigned to Jeremy in case he disagrees. Note also that it's preferable to submit patches in diff format, not as human-readable summaries. Try "diff -c". ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101335&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:21 -0700 Subject: [Patches] [Patch #101477] Fixes of ReadStream.readline() in UTF-16 and -LE codecs Message-ID: <200010181444.HAA14033@delerium.i.sourceforge.net> Patch #101477 has been updated. Project: Category: library Status: Open Summary: Fixes of ReadStream.readline() in UTF-16 and -LE codecs Follow-Ups: Date: 2000-Sep-14 07:09 By: fdrake Comment: Marc-Andre, please review this & decide what should happen next. ------------------------------------------------------- Date: 2000-Sep-18 09:28 By: lemburg Comment: I'm not sure whether this is the right fix: Unicode defines many more line break characters than just LF and the patch will only work correctly on Unix (also note that UTF-16 can be BE and LE -- your fix assumes LE). A true fix would have to also touch the .read() method and implement a true read-ahead buffer strategy to get this done right. ------------------------------------------------------- Date: 2000-Sep-19 03:41 By: lemburg Comment: Postponed until after the Python 2.0b2 release. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101477&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:25 -0700 Subject: [Patches] [Patch #101702] Modify co_filename in frozen programs Message-ID: <200010181444.HAA14069@delerium.i.sourceforge.net> Patch #101702 has been updated. Project: Category: demos and tools Status: Open Summary: Modify co_filename in frozen programs Follow-Ups: Date: 2000-Sep-29 04:39 By: lhudson Comment: A new feature for freeze. This patch was developed primarily to reduce the size of the frozen binary. It is particularly useful when freezing for 'small' platforms, such as Palm OS, where you really want to save that last miserable byte. A limitation of this patch is that it does not provide any feedback about the replacements being made. As the path matching is case-sensitive this may lead to unexpected behaviour for DOS and Windows people, eg > freeze.py -r C:\Python\Lib\=py\ goats.py should probably be: > freeze.py -r c:\python\lib\=py\ goats.py ------------------------------------------------------- Date: 2000-Sep-29 07:28 By: jhylton Comment: This sounds like a reasonable enough feature, but we are in feature freeze for Python 2.0. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101702&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:14 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:14 -0700 Subject: [Patches] [Patch #101186] IPv6 support in 1.6b1 (1.5.2 also available at ftp.kame.net) - from core@kame.net Message-ID: <200010181444.HAA13998@delerium.i.sourceforge.net> Patch #101186 has been updated. Project: Category: Modules Status: Open Summary: IPv6 support in 1.6b1 (1.5.2 also available at ftp.kame.net) - from core@kame.net Follow-Ups: Date: 2000-Aug-15 09:18 By: twouters Comment: This looks like PEP material. We actually discussed this briefly on python-dev, but there was noone there that had both the time and the knowledge to persue this. (I looked briefly at the 1.5.2 IPv6 implementation, but it raised too many questions to be added 'just like that', IMHO.) Would anyone from the team that wrote this feel like writing a PEP ? How involved are you in Python ? In absense of a volunteer to write a PEP, would there be a volunteer to explain design decisions ? (Hm, the person who submitted this patch did so anonymously. I'll forward the summary of this patch to core@kame.net) ------------------------------------------------------- Date: 2000-Aug-15 09:31 By: fdrake Comment: This will not go in Python 1.6. Python 2.0 is also closed for new features, so this should be taken up with Tim & Guido for 2.0. There is no good reason not to include this feature in Python 2.1; but I can't speak for the quality of the patch until I've had time to review it. Perhaps Python developers & testers knowledgable about IPv6 should get in touch with the person this patch is assigned to. ------------------------------------------------------- Date: 2000-Aug-15 15:30 By: tim_one Comment: Changed status to Postponed because it came in after 2.0 feature freeze. If you make a huge stink on Python-Dev and get a lot of support, cool, I'll re-Open it. Else it's for 2.1 at the earliest. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101186&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:07 -0700 Subject: [Patches] [Patch #100938] [Draft] libpython as shared library (.so) on Linux Message-ID: <200010181444.HAA13974@delerium.i.sourceforge.net> Patch #100938 has been updated. Project: Category: None Status: Open Summary: [Draft] libpython as shared library (.so) on Linux Follow-Ups: Date: 2000-Jul-19 14:10 By: flight Comment: This is what it used in product to build libpython as shared library(.so) for Debian. Note: This patch is not ready for inclusion in the upstream Python distribution. Anyway, I think this might be a start. The Python 1.5 executable in Debian GNU/Linux is built against a shared libpython1.5.so since April 1999, and I haven't yet heard about any problems. Using a shared library should have an advantage if you're running multiple instances of Python (be it standalone interpreter or embedded applications). ------------------------------------------------------- Date: 2000-Aug-15 10:52 By: tim_one Comment: Assigned to Barry because he's a Linux weenie. Barry, if you think there's something here that should go into 2.0, please pursue it now, else change the status to Postponed. ------------------------------------------------------- Date: 2000-Aug-16 00:40 By: moshez Comment: I suggest we postpone it. It isn't really complete (only works on real distributions ), and the complete solution should work on all unices. If Tcl/Perl can do it, there is no reason Python can't -- and a half hearted solution isn't that good. flight, you should use this for the Python in woody in the mean time -- I doubt woody will be stable before Python 2.1 comes out, so 2.1 sounds like a good timeframe to do it. ------------------------------------------------------- Date: 2000-Aug-23 09:26 By: jhylton Comment: In the absence of anyone arguing for inclusion of this patch and a one-week idle period, it is postponed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100938&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:26 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:26 -0700 Subject: [Patches] [Patch #101839] better error messages Message-ID: <200010181444.HAA14078@delerium.i.sourceforge.net> Patch #101839 has been updated. Project: Category: core (C code) Status: Open Summary: better error messages Follow-Ups: Date: 2000-Oct-08 20:20 By: ping Comment: This patch tries to make the feedback from error messages more consistent and helpful. For example: >>> os.kf Traceback (most recent call last): File "", line 1, in ? AttributeError: 'os' module has no attribute 'kf' >>> int(a=3) Traceback (most recent call last): File "", line 1, in ? TypeError: int() takes no keyword arguments >>> class Foo: pass ... >>> Foo.spam Traceback (most recent call last): File "", line 1, in ? AttributeError: class Foo has no attribute 'spam' >>> Foo().spam Traceback (most recent call last): File "", line 1, in ? AttributeError: Foo instance has no attribute 'spam' >>> Foo()() Traceback (most recent call last): File "", line 1, in ? AttributeError: Foo instance has no __call__ method This isn't really a bug, but it's not a feature either. I wanted to get it in before the Monday freeze. If you have time, have a look; i'll leave it to your judgement whether it's okay to check in. I know it's close to the wire, but it's effectively small: there are no changes in logic, only strings edited here and there. The corresponding changes to the tests that relied on specific wording of error messages are also included. ------------------------------------------------------- Date: 2000-Oct-08 20:26 By: ping Comment: More examples: >>> import os >>> del os.kf Traceback (most recent call last): File "", line 1, in ? AttributeError: 'os' module has no attribute 'kf' >>> pow(3,4,0) Traceback (most recent call last): File "", line 1, in ? ValueError: pow() arg 3 cannot be 0 >>> os.execv('a', 3) Traceback (most recent call last): File "", line 1, in ? TypeError: execv() arg 2 must be a tuple or list >>> os.execv('a', (3,4)) Traceback (most recent call last): File "", line 1, in ? TypeError: execv() arg 2 must contain only strings >>> 0 ** -4 Traceback (most recent call last): File "", line 1, in ? ZeroDivisionError: cannot raise 0 to a negative power >>> int("45", 1) Traceback (most recent call last): File "", line 1, in ? ValueError: int() base must be >= 2 and <= 36 >>> ord(3) Traceback (most recent call last): File "", line 1, in ? TypeError: ord() expected string or Unicode character, int found ------------------------------------------------------- Date: 2000-Oct-08 20:28 By: ping Comment: Forgot to mention that this patch also includes changed names for audio formats in the linuxaudiodev module. ------------------------------------------------------- Date: 2000-Oct-09 05:32 By: gvanrossum Comment: Sorry, but this has to go in after 2.0 final is released. It's touching way too much code to be snuck in at the very last moment. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101839&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:22 -0700 Subject: [Patches] [Patch #101527] ustr Message-ID: <200010181444.HAA14044@delerium.i.sourceforge.net> Patch #101527 has been updated. Project: Category: None Status: Open Summary: ustr Follow-Ups: Date: 2000-Sep-15 03:17 By: htrd Comment: In July on i18n-sig, we discussed the need for a builtin function like "str" but which could return any string-like object. Guido endorsed the idea http://www.python.org/pipermail/i18n-sig/2000-July/000338.html but no patch has been submitted. I know its too late to add this as a builtin for 2.0. Is it too late to add it to the string module? ------------------------------------------------------- Date: 2000-Sep-15 06:16 By: gvanrossum Comment: I think we should not do this now. A feature freeze is a feature freeze. :-) Let's see if the need really exists once 2.0 is released and then we can add it to 2.1. I'm sure there are lots of other things that we find would be useful to add, once there's some real experience using the new Unicode stuff. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101527&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:48:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:48:34 -0700 Subject: [Patches] [Patch #101842] Localization of calendar module. Message-ID: <200010181448.HAA14288@delerium.i.sourceforge.net> Patch #101842 has been updated. Project: Category: library Status: Open Summary: Localization of calendar module. Follow-Ups: Date: 2000-Oct-09 01:34 By: ods Comment: This work fine for all locales on NT, but may work a bit strange with some locales (e.g. ru_RU) on some platforms with buggy (IMHO) L10n of strftime (e.g. RedHat Linux). ------------------------------------------------------- Date: 2000-Oct-09 05:46 By: gvanrossum Comment: This seems a little too much code while we're in a feature freeze. Let's do this after 2.0final is released. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101842&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:17 -0700 Subject: [Patches] [Patch #101313] New builtin function doc Message-ID: <200010181444.HAA14014@delerium.i.sourceforge.net> Patch #101313 has been updated. Project: Category: library Status: Open Summary: New builtin function doc Follow-Ups: Date: 2000-Aug-26 11:36 By: twouters Comment: Someone (Vladimir, I think ?) was working on a help() function, which was a docstring-prettyprinter as well as helpful in many other ways. I also think doc() should only be defined in interactive mode, but that's personal. ------------------------------------------------------- Date: 2000-Aug-27 02:13 By: moshez Comment: Assigned to Jeremy, so he can postpone it. It's definitely not-for-2.0 stuff. ------------------------------------------------------- Date: 2000-Aug-28 00:43 By: tim_one Comment: Postponed it as requested (why didn't you do that yourself?). Left assigned to Jeremy for post-2.0 resurrection. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101313&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:18 -0700 Subject: [Patches] [Patch #101320] Translate doc strings Message-ID: <200010181444.HAA14017@delerium.i.sourceforge.net> Patch #101320 has been updated. Project: Category: library Status: Open Summary: Translate doc strings Follow-Ups: Date: 2000-Aug-28 00:46 By: tim_one Comment: Assigned to Barry since it seems related to gettext. ------------------------------------------------------- Date: 2000-Aug-30 12:38 By: gvanrossum Comment: Barry will comment on this and then postpone it. ------------------------------------------------------- Date: 2000-Aug-31 14:22 By: bwarsaw Comment: We're postponing this patch for 2.0 for a couple of reasons. First, it seems that more discussion about exactly how to distribute translations of docstrings should take place on the i18n-sig. Second, these files are fairly large so they probably shouldn't go into the core Python distribution, although some infrastructure is need to get these to translators, and back to end users. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101320&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:16 -0700 Subject: [Patches] [Patch #101264] Attribute Doc-Strings Message-ID: <200010181444.HAA14011@delerium.i.sourceforge.net> Patch #101264 has been updated. Project: Category: core (C code) Status: Open Summary: Attribute Doc-Strings Follow-Ups: Date: 2000-Aug-23 02:22 By: lemburg Comment: This patch implements the proposed addition of doc-strings for e.g. class attribute, module attributes, etc. See the upcoming PEP for details (the PEP was already submitted to the PEP editor for review). Here's a shot excerpt: class C: " class C doc-string " a = 1 " attribute C.a doc-string (1)" b = 2 " attribute C.b doc-string (2)" results in following new class attributes to be created: C.__doc__a__ == " attribute C.a doc-string (1)" C.__doc__b__ == " attribute C.b doc-string (2)" ------------------------------------------------------- Date: 2000-Aug-23 08:21 By: tim_one Comment: Postponed due to 2.0 feature freeze and assigned to the release manager for re-opening. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101264&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:28 -0700 Subject: [Patches] [Patch #101843] Remove all uses of "assert" from the test suite Message-ID: <200010181444.HAA14089@delerium.i.sourceforge.net> Patch #101843 has been updated. Project: Category: core (C code) Status: Open Summary: Remove all uses of "assert" from the test suite Follow-Ups: Date: 2000-Oct-09 07:25 By: lemburg Comment: This patch removes all uses of the assert statement from the regression test suite. Use of assert in the suite is depreciated due to asserts being removed from the byte code when Python is run in optimized mode. The patch adds a new function to test_support (verify) which handles the asserts in a more customizable way. It does not rely on the assert statement. I have tested this patch lightly (meaning that the suite runs through just fine). Not all execution paths are testable due to the nature of the patch, though. Please review. ------------------------------------------------------- Date: 2000-Oct-09 12:26 By: gvanrossum Comment: Great! But let's do this post-2.0 final release. I'm really getting worried about patches that touch every file in a particular corner of the universe... :-( ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101843&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:28 -0700 Subject: [Patches] [Patch #101843] Remove all uses of "assert" from the test suite Message-ID: <200010181444.HAA14090@delerium.i.sourceforge.net> Patch #101843 has been updated. Project: Category: core (C code) Status: Open Summary: Remove all uses of "assert" from the test suite Follow-Ups: Date: 2000-Oct-09 07:25 By: lemburg Comment: This patch removes all uses of the assert statement from the regression test suite. Use of assert in the suite is depreciated due to asserts being removed from the byte code when Python is run in optimized mode. The patch adds a new function to test_support (verify) which handles the asserts in a more customizable way. It does not rely on the assert statement. I have tested this patch lightly (meaning that the suite runs through just fine). Not all execution paths are testable due to the nature of the patch, though. Please review. ------------------------------------------------------- Date: 2000-Oct-09 12:26 By: gvanrossum Comment: Great! But let's do this post-2.0 final release. I'm really getting worried about patches that touch every file in a particular corner of the universe... :-( ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101843&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:21 -0700 Subject: [Patches] [Patch #101416] coax _sre.c into using Py_GetRecursionLimit() Message-ID: <200010181444.HAA14032@delerium.i.sourceforge.net> Patch #101416 has been updated. Project: Category: Modules Status: Open Summary: coax _sre.c into using Py_GetRecursionLimit() Follow-Ups: Date: 2000-Sep-04 09:02 By: montanaro Comment: seems obvious that Fredrik should be the one to handle this... ------------------------------------------------------- Date: 2000-Sep-15 07:21 By: fdrake Comment: The declaration of rlimit should be wrapped in #ifdef USE_RECURSION_LIMIT / #endif, since it isn't used otherwise. ------------------------------------------------------- Date: 2000-Sep-15 08:26 By: montanaro Comment: thanks - new version adds the appropriate ifdef ------------------------------------------------------- Date: 2000-Sep-22 05:54 By: fdrake Comment: Fredrik, are there problems with this patch? Does it not make sense? Please take action on this. ------------------------------------------------------- Date: 2000-Sep-25 09:50 By: montanaro Comment: Postponing this is okay with me, but I am almost certain the new _sre module is going to cause problems for nasty regular expressions that the 1.5.2 re module could handle. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101416&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:09 -0700 Subject: [Patches] [Patch #101019] Opcode reordering Message-ID: <200010181444.HAA13980@delerium.i.sourceforge.net> Patch #101019 has been updated. Project: Category: core (C code) Status: Open Summary: Opcode reordering Follow-Ups: Date: 2000-Jul-30 01:34 By: marangoz Comment: Mainly for peace of mind - as discussed on python-dev, aims at reducing cache effects. The Top5 opcodes have been moved to the beginning of the main loop, ordered by decreasing frequency according to DXP and MAL's statistics. LOAD_FAST & LOAD_CONST have been slightly tweaked so that the code sequence is 'unique' amongst the other opcodes. Otherwise, the optimizer is likely to generate a jump to another common block later in the loop which obviates the whole point of moving these opcodes to the top. - The condition in LOAD_FAST is inversed - LOAD_CONST has been changed from 'break' to 'continue'. Indeed, if x == NULL, we would have dumped core at the Py_INCREF(x) preceding the break... Some testing on Lunix, Solaris and AIX shows no slowdowns . There seems to be some speedup, but in some cases it is barely noticeable. I dropped the idea of folding opcodes. The bahavior is unpredictable. If someone wants to spend her entire life between balancing caching and pipelining in ceval.c, no problem . I'm out of this game. As usual, please test (notably on Windows) ------------------------------------------------------- Date: 2000-Jul-31 06:43 By: gvanrossum Comment: Status set to Postponed, just to indicate that this is still experimental and not slated for inclusion into 2.0. Thanks for submitting this though -- it's good that it's recorded somewhere. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101019&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:25 -0700 Subject: [Patches] [Patch #101782] Enhances 1.6 compiler to raise 'proper' SyntaxErrors Message-ID: <200010181444.HAA14075@delerium.i.sourceforge.net> Patch #101782 has been updated. Project: Category: Parser/Compiler Status: Open Summary: Enhances 1.6 compiler to raise 'proper' SyntaxErrors Follow-Ups: Date: 2000-Oct-04 12:29 By: Roman_Sulzhyk Comment: Hello: There's a problem with the compiler.c (which persists in 2.0 also) which means it raises 'old style' SyntaxErrors, which could not be formatted properly. I mentioned this to Guido during the last conference, and he said it can best be done by moving parts of the 'linecache' functionality to core python, or something along those lines. Well, I've put together something which is not so far-fetching, but plugs this hole. The only time it reverts to the 'old style' compile error is when the input file is not a regular file (like stdin), since the line information is lost at that point - don't think parser.c saves it anywhere. Tell me what you think - should I port it to 2.0, or just drop it altogether if it's not needed. Thanks, Roman ------------------------------------------------------- Date: 2000-Oct-04 23:40 By: fdrake Comment: This needs to be ported to the latest CVS version before being considered for implementation (but discussion of the feature is welcome!). This cannot be considered for inclusion in 2.0 since we're in feature freeze already, and are only fixing bugs at this point. This can be considered for 2.1. Marking as postponed. ------------------------------------------------------- Date: 2000-Oct-09 10:59 By: Roman_Sulzhyk Comment: I've ported it to the latest CVS version - check it out, Roman ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101782&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:00 -0700 Subject: [Patches] [Patch #100803] puremodule: ANSI-fication (UNTESTED!) Message-ID: <200010181444.HAA13965@delerium.i.sourceforge.net> Patch #100803 has been updated. Project: Category: None Status: Open Summary: puremodule: ANSI-fication (UNTESTED!) Follow-Ups: Date: 2000-Jul-10 10:16 By: nowonder Comment: cannot test this, maybe Barry can ------------------------------------------------------- Date: 2000-Jul-31 01:46 By: nowonder Comment: should I just check it in? Did you get around to review it? ------------------------------------------------------- Date: 2000-Jul-31 09:30 By: bwarsaw Comment: There's one typo in nowonder's patch. Here's a fixed version of the patch (unified). This compiles but doesn't link. I can't tell if this is caused by a problem with the purify stub libraries. Meta note: because this is a commercial product which it seems no one has access to anymore, should we continue to support it in the standard distribution? ------------------------------------------------------- Date: 2000-Jul-31 10:30 By: gvanrossum Comment: Since no-one can test this, let's be conservative and not check it in. There's no absolute requirement to move *everything* to ANSI. Since we know the old version worked, we should leave it alone. I vote to keep this in the distribution -- maybe someone else can use it. If someone else can confirm that it in fact works (or make it work) I'd be happy to accept the patch at that point. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100803&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:24 -0700 Subject: [Patches] [Patch #101651] Gracefully detect usage of old extension module Message-ID: <200010181444.HAA14062@delerium.i.sourceforge.net> Patch #101651 has been updated. Project: Category: Windows Status: Open Summary: Gracefully detect usage of old extension module Follow-Ups: Date: 2000-Sep-25 12:49 By: loewis Comment: Also see commentary inside the patch. ------------------------------------------------------- Date: 2000-Sep-25 16:46 By: tim_one Comment: Assigned to MarkH. Mark, if you've got the bandwidth to think about this immediately, and like it, say so within the next couple of hours and I'll sneak it into 2.0b2. Else Postpone it. ------------------------------------------------------- Date: 2000-Sep-25 19:16 By: mhammond Comment: My theoretical objection to this is that it may be possible for a single process to have both Python 1.5 and Python 2.0 embedded - eg, a Web server. The issue is "does the extension I just loaded reference Python15.dll", rather than simply "is python15.dll used by anyone in this process" Like I said, mainly theoretical, but there is no reason I can think of why this would not work today for people, so we can only assume it is! Marked as postponed. ------------------------------------------------------- Date: 2000-Sep-25 19:24 By: tim_one Comment: Thank you, Mark. I made enough crisis-mode work for myself by championing other last-second changes that I can't afford to argue with you now even if I wanted to . But I don't want to, so Postponing was the right thing all around. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101651&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:24 -0700 Subject: [Patches] [Patch #101651] Gracefully detect usage of old extension module Message-ID: <200010181444.HAA14063@delerium.i.sourceforge.net> Patch #101651 has been updated. Project: Category: Windows Status: Open Summary: Gracefully detect usage of old extension module Follow-Ups: Date: 2000-Sep-25 12:49 By: loewis Comment: Also see commentary inside the patch. ------------------------------------------------------- Date: 2000-Sep-25 16:46 By: tim_one Comment: Assigned to MarkH. Mark, if you've got the bandwidth to think about this immediately, and like it, say so within the next couple of hours and I'll sneak it into 2.0b2. Else Postpone it. ------------------------------------------------------- Date: 2000-Sep-25 19:16 By: mhammond Comment: My theoretical objection to this is that it may be possible for a single process to have both Python 1.5 and Python 2.0 embedded - eg, a Web server. The issue is "does the extension I just loaded reference Python15.dll", rather than simply "is python15.dll used by anyone in this process" Like I said, mainly theoretical, but there is no reason I can think of why this would not work today for people, so we can only assume it is! Marked as postponed. ------------------------------------------------------- Date: 2000-Sep-25 19:24 By: tim_one Comment: Thank you, Mark. I made enough crisis-mode work for myself by championing other last-second changes that I can't afford to argue with you now even if I wanted to . But I don't want to, so Postponing was the right thing all around. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101651&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:23 -0700 Subject: [Patches] [Patch #101612] Prevent recursion limit when using ".*?xxx" Message-ID: <200010181444.HAA14050@delerium.i.sourceforge.net> Patch #101612 has been updated. Project: Category: Modules Status: Open Summary: Prevent recursion limit when using ".*?xxx" Follow-Ups: Date: 2000-Sep-22 21:12 By: dgallion Comment: This pattern fails with sre: >>> re.match("(?s){.*?}","{"+' '*17000+"}") Traceback (most recent call last): File "", line 1, in ? File "E:\pythonWinCVS\python\dist\src\lib\sre.py", line 44, in match return _compile(pattern, flags).match(string) RuntimeError: maximum recursion limit exceeded The same pattern with even a much larger search buffer works fine on 1.52 This patch optimizes the case ".*?" and avoids the recursion limit. After the patch: >>> import re >>> re.findall('ab.*?bc', 'abababbc') ['abababbc'] >>> re.findall('ab??bc', 'abababbc') ['abbc'] >>> re.sub("(?s){.*?}","","{"+' '*19047+"}") '' >>> re.match("(?s){.*?}","{"+' '*16048+"}") >>> import test.test_re Running tests on re.search and re.match Running tests on re.sub Running tests on symbolic references Running tests on re.subn Running tests on re.split Running tests on re.findall Running tests on re.match Running tests on re.escape Pickling a RegexObject instance Test engine limitations maximum recursion limit exceeded Running re_tests test suite >>> ------------------------------------------------------- Date: 2000-Sep-22 21:23 By: tim_one Comment: Assigned to Fredrik. dgallion, please resubmit a context diff. Straight diffs aren't accepted (they're too brittle). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101612&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:23 -0700 Subject: [Patches] [Patch #101612] Prevent recursion limit when using ".*?xxx" Message-ID: <200010181444.HAA14051@delerium.i.sourceforge.net> Patch #101612 has been updated. Project: Category: Modules Status: Open Summary: Prevent recursion limit when using ".*?xxx" Follow-Ups: Date: 2000-Sep-22 21:12 By: dgallion Comment: This pattern fails with sre: >>> re.match("(?s){.*?}","{"+' '*17000+"}") Traceback (most recent call last): File "", line 1, in ? File "E:\pythonWinCVS\python\dist\src\lib\sre.py", line 44, in match return _compile(pattern, flags).match(string) RuntimeError: maximum recursion limit exceeded The same pattern with even a much larger search buffer works fine on 1.52 This patch optimizes the case ".*?" and avoids the recursion limit. After the patch: >>> import re >>> re.findall('ab.*?bc', 'abababbc') ['abababbc'] >>> re.findall('ab??bc', 'abababbc') ['abbc'] >>> re.sub("(?s){.*?}","","{"+' '*19047+"}") '' >>> re.match("(?s){.*?}","{"+' '*16048+"}") >>> import test.test_re Running tests on re.search and re.match Running tests on re.sub Running tests on symbolic references Running tests on re.subn Running tests on re.split Running tests on re.findall Running tests on re.match Running tests on re.escape Pickling a RegexObject instance Test engine limitations maximum recursion limit exceeded Running re_tests test suite >>> ------------------------------------------------------- Date: 2000-Sep-22 21:23 By: tim_one Comment: Assigned to Fredrik. dgallion, please resubmit a context diff. Straight diffs aren't accepted (they're too brittle). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101612&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:21 -0700 Subject: [Patches] [Patch #101482] fix for Bug #114245 Message-ID: <200010181444.HAA14038@delerium.i.sourceforge.net> Patch #101482 has been updated. Project: Category: core (C code) Status: Open Summary: fix for Bug #114245 Follow-Ups: Date: 2000-Sep-16 16:18 By: tim_one Comment: Mark, does this look reasonable to you? The thrust is to make utime work for directories under Win32 (as well as for files). THere's also an entry for this one in PEP 42 (Feature Requests). ------------------------------------------------------- Date: 2000-Sep-16 16:31 By: mhammond Comment: With a quick look and no decent analysis, I can't see a good reason why this wouldnt work. However, see http://support.microsoft.com/support/kb/articles/q167/2/96.asp for the official way of doing this - it is significantly different. I have the above KB code all Python-ready, as it was used in the Windows CE port. I am happy to send this to anyone and everyone, but I am afraid I don't have time to rework the patch. Also note that I would _love_ to see whatever conversion routine you add made public in the DLL (and hence named appropriately). Windows CE could use it, as could the Python Win32 extensions - keep the bloat size down by keeping it in Python, and the cost of making it public isnt too bad! ------------------------------------------------------- Date: 2000-Sep-16 19:40 By: none Comment: The time conversion function time2Time is modeled after MS C run time library code. It looks official way of doing this also ;). However UnixTimeToFileTime looks simpler. But I do not know if these two functions do the same thing. ------------------------------------------------------- Date: 2000-Sep-17 18:35 By: tim_one Comment: I changed this to Postponed: the scope is growing, and the bug this is related to was already changed to a Feature Request and added to PEP 42. Let's look at it again after 2.0final. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101482&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:19 -0700 Subject: [Patches] [Patch #101352] PyOS_StackCheck for Unix Message-ID: <200010181444.HAA14021@delerium.i.sourceforge.net> Patch #101352 has been updated. Project: Category: core (C code) Status: Open Summary: PyOS_StackCheck for Unix Follow-Ups: Date: 2000-Aug-30 02:15 By: lemburg Comment: Since getrlimit() might not return useful results on all Unix platforms, I'd suggest adding a test to the configure script (the test should check whether getrlimit() returns a non-zero value for the stack limit). Also, due to the added call overhead, I'd suggest raising the modulo value in ceval's hook to call PyOS_CheckStack(): #ifdef USE_STACKCHECK if (tstate->recursion_depth%10 == 0 && PyOS_CheckStack()) { PyErr_SetString(PyExc_MemoryError, "Stack overflow"); return NULL; } #endif to about 100. That way the stack check will most likely only be triggered by programs which actually use recursion, rather than those which only use shallow function call nesting (10 seems to low w/r to these). ------------------------------------------------------- Date: 2000-Aug-30 05:31 By: loewis Comment: IMO, testing could be deferred until some system shows up that indeed returns zero. As for the frequency of the OS call, it may be useful to cache the result of getrlimit, on a per-thread basis. That won't catch changes done by the script itself, or from the outside, but if people do such things, they need to be careful, anyway. ------------------------------------------------------- Date: 2000-Aug-30 12:52 By: gvanrossum Comment: Given to Jeremy. We don't think we can get PyOS_CheckStack to work reliably and efficiently on Unix. Instead, we're going to make the recursion limit a user settable thing (sys.{set,get}recursionlimit) with a small default, e.g. 1000. ------------------------------------------------------- Date: 2000-Aug-30 18:33 By: jhylton Comment: Postponed, because it is sufficiently complex to fall subject to the feature freeze for 2.0b1. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101352&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:12 -0700 Subject: [Patches] [Patch #101137] Add raw packet support to socketmodule.c Message-ID: <200010181444.HAA13989@delerium.i.sourceforge.net> Patch #101137 has been updated. Project: Category: Modules Status: Open Summary: Add raw packet support to socketmodule.c Follow-Ups: Date: 2000-Aug-09 14:49 By: grante Comment: Patch has only been tested on Linux: RH6.2 (Intel). Patch is against 1.6b1 ------------------------------------------------------- Date: 2000-Aug-15 15:15 By: tim_one Comment: Assigned to Barry, since he just volunteered to rewrite all of Python's socket code anyway . ------------------------------------------------------- Date: 2000-Aug-24 14:27 By: jhylton Comment: Not sure about this patch. It needs to be tested on more platforms than just Linux, but I don't see that we'll have time before 2.0. There are several other issues that must be resolved, too. Thus, this patch falls subject to the feature freeze. Style points: Indention is wrong. The opening curly brace of an if belongs on the same line as the test. Whitespace is required around = and after commas in argument lists. The strncpy in makesockaddr does not check the size of the source string. It could overflow the buffer. In makesockaddr, a new socket is created just to look up the interface name associated with a particular interface. This seems wasteful, particularly in cases where few file descriptors are available. I'm not sure what the solution is, although it might be to change the makesockaddr function so that it takes the socket itself. Perhaps that socket address for AF_PACKET should also accept and/or produce interface numbers which the client can convert to names manually. The sockaddr_ll has members ssl_hatype and ssl_pkttype, which are not made accessible by this patch. It seems like they should be, but I am not sure. Can you use SOCK_DGRAM without specifying the packet type? getsockaddrarg is handled, but getsockaddrlen is not. Question: Are there any other constants that should be added? This relates to the packet type question. * ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101137&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:13 -0700 Subject: [Patches] [Patch #101162] a Python/C API testing framework (simple simple) Message-ID: <200010181444.HAA13992@delerium.i.sourceforge.net> Patch #101162 has been updated. Project: Category: Build Status: Open Summary: a Python/C API testing framework (simple simple) Follow-Ups: Date: 2000-Aug-11 13:37 By: tmick Comment: Here is a proposed patch for a Python/C API testing framework. Simple simple. Basic Overview: - add a _test C extension module that exports test functions beginning with 'test_'; NULL and a TestError exception indicates a test failure and Py_None indicate a test pass - add a test_capi.py test module that calls each of the 'test_' exported functions in the '_test' module - changes to the build system files for Win32 and Unix are includes to build _testmodule.c as a shared extension - new files: Lib/test/test_capi.py, Lib/test/output/test_capi, Modules/_testmodule.c, and PCbuild/_test.dsp ------------------------------------------------------- Date: 2000-Aug-11 13:48 By: tmick Comment: don't use C++ style comments ------------------------------------------------------- Date: 2000-Aug-12 13:46 By: tmick Comment: Skip, You seemed to have some interest in this the couple of times it came up on python-dev. I wonder if you might want to review this. No rush, I don't expect this to go in anytime soon. Unless, of course, people just *have* to have it. ------------------------------------------------------- Date: 2000-Aug-15 15:23 By: tim_one Comment: Sorry, but there is a rush! Since Python 2.0 is scheduled to have only 1 beta cycle, if this doesn't make it into the beta (< 2 weeks, according to the schedule), it's for 2.1 at best. It would be very good to have a start at this (no matter how simple) in place for 2.0. ------------------------------------------------------- Date: 2000-Aug-16 12:05 By: tmick Comment: re: delaying to 2.1: doesn't bother me much Should it now be "postponed", Tim? ------------------------------------------------------- Date: 2000-Aug-21 19:54 By: montanaro Comment: postponed until 2.1 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101162&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:11 -0700 Subject: [Patches] [Patch #101022] Removal of SET_LINENO (experimental) Message-ID: <200010181444.HAA13983@delerium.i.sourceforge.net> Patch #101022 has been updated. Project: Category: core (C code) Status: Open Summary: Removal of SET_LINENO (experimental) Follow-Ups: Date: 2000-Jul-30 16:12 By: marangoz Comment: For testing, as discussed on python-dev. For a gentle summary, see: http://www.python.org/pipermail/python-dev/2000-July/014364.html ------------------------------------------------------- Date: 2000-Jul-30 18:16 By: marangoz Comment: A nit: inline the argfetch in CALL_TRACE and goto the switch, instead of jumping to get_oparg which splits the sequence [fetch opcode, fetch oparg] -- this can slow things down. ------------------------------------------------------- Date: 2000-Jul-31 06:40 By: gvanrossum Comment: Status set to postponed to indicate that this is still experimental. ------------------------------------------------------- Date: 2000-Jul-31 07:57 By: marangoz Comment: Another rewrite, making this whole strategy b/w compatible according to the 1st incompatibility point a) described in: http://www.python.org/pipermail/python-dev/2000-July/014364.html Changes: 1. f.f_lineno is computed and updated on f_lineno attribute requests for f, given f.f_lasti. Correctness is ensured because f.f_lasti is updated on *all* attribute accesses (in LOAD_ATTR in the main loop). 2. The standard setup does not generate SET_LINENO, but uses co_lnotab for computing the source line number (e.g. tracebacks) This is equivalent to the actual "python -O". 3. With "python -d", we fall back to the current version of the interpreter (with SET_LINENO) thus making it easy to test whether this patch fully replaces SET_LINENO's behavior. (modulo f->f_lineno accesses from legacy C code, but this is insane). IMO, this version already worths the pain to be truly tested and improved. One improvement is to define a nicer public C API for breakpoints: - PyCode_SetBreakPointAtLine(line) - PyCode_SetBreakPointAtAddr(addr) or similar, which would install a CALL_TRACE opcode in the appropriate location of the copy of co_code. Another idea is to avoid duplicating the entire co_code just for storing the CALL_TRACE opcodes. We can store them in the original and keep a table of breakpoints. Setting the breakpoints would occur whenever the sys.settrace hook is set. ------------------------------------------------------- Date: 2000-Jul-31 10:50 By: marangoz Comment: A last tiny fix of the SET_LINENO opcode for better b/w compatibility. Stopping here and entering standby mode for reactions & feedback. PS: the last idea about not duplicating co_code and tweaking the original with CALL_TRACE is a bad one. I remember Guido being against it because co_code could be used elsewhere (copied, written to disk, whatever) and he's right! Better operate on an internal copy created in ceval. ------------------------------------------------------- Date: 2000-Aug-03 12:22 By: marangoz Comment: Fix missing DECREF on error condition in start_tracing() + some renaming. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101022&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:08 -0700 Subject: [Patches] [Patch #100998] experimental support for extended slicing on lists Message-ID: <200010181444.HAA13977@delerium.i.sourceforge.net> Patch #100998 has been updated. Project: Category: core (C code) Status: Open Summary: experimental support for extended slicing on lists Follow-Ups: Date: 2000-Jul-27 14:31 By: mwh Comment: this 10 minute hack adds support for "extended slicing" to lists, by which I mean things like: >>> range(100)[23:60:12] [23, 35, 47, 59] todo: find out if this is the approved approach add support for tuples write docs, testsuite (make test passes as is, but should be extended). ------------------------------------------------------- Date: 2000-Jul-27 14:39 By: mwh Comment: c'mon michael! at least get *some* of the boundary cases... ------------------------------------------------------- Date: 2000-Jul-27 23:47 By: mwh Comment: negative indices! for i in listvar[::-1]: pass now iterates over the list backwards (rather than coredumping...) ------------------------------------------------------- Date: 2000-Jul-29 03:36 By: mwh Comment: updated patch to support slice assignements, deletions (needs testing still) ------------------------------------------------------- Date: 2000-Jul-30 11:10 By: mwh Comment: bugfixes (refounting in assignment, logic in deletion) & a few tweaks. ------------------------------------------------------- Date: 2000-Jul-30 11:41 By: mwh Comment: meep! naughty Michael hadn't been running "make test" often enough. this update fixes that. ------------------------------------------------------- Date: 2000-Aug-15 11:53 By: tim_one Comment: Note that without doc and test patches too, and Real Soon, I'll have to Postpone this. Assigned to me to remind me of that. ------------------------------------------------------- Date: 2000-Aug-15 12:04 By: mwh Comment: OK, I'll get to that soon (ie. <24hours, hopefully <4). But bear in mind I'm now going to the pub... I may need some advice for the docs... ------------------------------------------------------- Date: 2000-Aug-16 12:30 By: mwh Comment: So, I missed my deadline by twenty five minutes. Sorry :-) This latest patch adds a fairly basic test suite, a stab at some docs, and jumps up and down on PySlice_GetIndices. Also (wrt. stringobject.c & unicodeobject.c) it's amazing what you can break, isn't it? Thank God for test suites... ------------------------------------------------------- Date: 2000-Aug-16 12:30 By: mwh Comment: So, I missed my deadline by twenty five minutes. Sorry :-) This latest patch adds a fairly basic test suite, a stab at some docs, and jumps up and down on PySlice_GetIndices. Also (wrt. stringobject.c & unicodeobject.c) it's amazing what you can break, isn't it? Thank God for test suites... ------------------------------------------------------- Date: 2000-Aug-31 19:10 By: gvanrossum Comment: Too late for the release, sorry. And Tim hates negative strides. We'll get back to this for 2.1. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100998&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:13 -0700 Subject: [Patches] [Patch #101170] Prevent old extensions from crashing Message-ID: <200010181444.HAA13995@delerium.i.sourceforge.net> Patch #101170 has been updated. Project: Category: Windows Status: Open Summary: Prevent old extensions from crashing Follow-Ups: Date: 2000-Aug-12 01:55 By: chega Comment: This patch will prevent old (1.5/1.6) extensions from crashing under Python 2.0 (Also changed pathbuf[260] to pathbuf[MAX_PATH]) ------------------------------------------------------- Date: 2000-Aug-15 15:26 By: tim_one Comment: Assigned to MarkH. Please review or pass on to someone else. ------------------------------------------------------- Date: 2000-Aug-15 16:26 By: mhammond Comment: I'm not sure this is worth adding. Note that we already have code to prevent a crash in place - however, rather than raising an exception it simply calls Py_FatalError. This patch is potentially better, except that: * It will require regressing the patch made to modsupport.c (Rev 2.50) to prevent the same problem; that code will prevent this code kicking in! * It hard-codes the Python DLL names. This makes long term maintenance a PITA, and yet another file that needs to be updated when a version bumps. Are there other alternatives? * Once the module has been loaded, it may be too late to save the process anyway. I realize that the module init hasnt been called yet, but the module has been loaded, and may be doing things in its DllMain() that will destabilize the process. The big killer is simply that this code will never be triggered, as the check in modsupport.c will kick in first. Setting to postponed until we can get a better handle on this. A big advantage is that this style of change is not dependent on _old_ versions having the patch, only one actually running. Hence we can revive this patch at any time, and have it start working immediately. ------------------------------------------------------- Date: 2000-Aug-15 16:49 By: tim_one Comment: I agree with Postponing it. Thanks for the quick response! Feel like reviewing 7 controversial getopt patches now ? ------------------------------------------------------- Date: 2000-Aug-15 17:10 By: chega Comment: * The patch to modsupport.c will NOT save us in the case when someone loads 1.5 extension. See Guido's checkin comment. And I think that Python 1.6 will never be widely spread anyways, so in 99.9% cases it'll be 1.5 vs 2.0. * I agree that the hard-coded dll-names are PITA, but only a small one :-). The version check #if will make sure that this list gets updated. Also, if we keep Guido's patch in modsupport.c the list won't need updating. * I'd rather have an ImportError that PyFatalError() * I find the argument about DllMain() screwing up the process somewhat err... artificial ;-))) I have never seen such a module. Have you? The only thing I am not sure about is whether there is any legitimate reason to have python15 loaded. AFAIR, python COM servers are alwaus out-of-process, aren't they? Can you think of something else? If such reasons do exist, we may want to put another check before loading the module and then bypass the post-check if python15 has been already loaded. ------------------------------------------------------- Date: 2000-Aug-21 05:38 By: mhammond Comment: Another alternative would be to create a Win32 event object, with name "Python-%d" % pid, and have DllMain() attempt to acquire it. This would prevent the "old" Python subsystem starting at all, nipping it right in the bud (and should return a clean ImportError back to the caller!) Does this sound worthwhile? ------------------------------------------------------- Date: 2000-Aug-21 05:43 By: mhammond Comment: Oops - I should have mentioned - Jack Jansen mailed me with the DllMain() idea :-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101170&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:25 -0700 Subject: [Patches] [Patch #101713] Free extension DLLs' handles during the Py_Finalize() Message-ID: <200010181444.HAA14074@delerium.i.sourceforge.net> Patch #101713 has been updated. Project: Category: Windows Status: Open Summary: Free extension DLLs' handles during the Py_Finalize() Follow-Ups: Date: 2000-Sep-29 12:09 By: Markovitch Comment: This patch is intended to fix the following problem: Python on Windows never frees DLLs loaded as extension. Whenever it's not a big problem when the interpreter is being used in a standart way, it becomes THE problem (or even a disaster) when the interpreter DLL is dynamically initialized/finalized from one process many times during single run. Moreover, even in case of single initialization there is a trap - DLLs loaded by mistake are unloaded only then a process finishes (e.g. suppose there is a foo.dll in the current directory and foo.dll is NOT a Python extension; "import foo" ends up with error, but foo.dll will be anging in process' address space!) This patch 1) frees a DLL handle in case of it has no proper initialization funcion 2) registers in an internal array all handles of successfully loaded dynamic extensions 2) frees all registered handles during Py_Finalize() Yakov Markovitch, markovitch@iso.ru ------------------------------------------------------- Date: 2000-Sep-30 17:01 By: fdrake Comment: Assigned to one of our Windows guys for review. ------------------------------------------------------- Date: 2000-Sep-30 17:01 By: fdrake Comment: Assigned to one of our Windows guys for review. ------------------------------------------------------- Date: 2000-Oct-05 18:02 By: tim_one Comment: Mark, you got anything to say about this? Can't say I've ever noticed a problem here. Note that "the patch" is actually a .zip archive, and it takes a little effort to sort out what's what. ------------------------------------------------------- Date: 2000-Oct-05 18:19 By: mhammond Comment: I agree we should close handles that we can't use as extension modules. I am quite skeptical of the unloading of modules, tho. Python simply doesn't provide enough cleanup semantics to guarantee we are finished with the module at Py_Finalize() time. Indeed, extension modules are one main reason why Python often can not handle multiple Py_Initialize()/Py_Finalize() calls in the same process. I think that Python needs to grow module termination semantics. Something like, at Py_Finalize time: Try and find function "term_{module}" If function exists: call function free handle else: pass Thus - only modules that have gone to the trouble of providing a finalize function can be trusted to be unloaded. On one hand, the addition of the map means we _are_ in a better position for better finalization semantics on Windows. On the larger hand, module finalization semantics must be cross-platform anyway. So - while I acknowledge the problem, I don't believe this alone is a reasonable solution. Marking as postponed, and assigning back to Tim, so he can rule on the next step.... This came up a number of years ago, and Guido agreed "better" semantics were needed. Sounds like PEP material. I guess I _do_ care enough about this issue to own a PEP on it, as long as no-one needs the PEP finalized this year ;-) ------------------------------------------------------- Date: 2000-Oct-06 02:54 By: Markovitch Comment: Yes, I agree with Mark, but there is the other side of the problem. Let's suppose that we have an application that uses the interpreter through dynamic loading (I mean through the LoadLibrary). It isn't likely to be directly, but the application can load/unload some other DLL which, in turn, uses an embedded interpreter. Now after freeing this DLL the application has ALL extensions which was used by this DLL loaded! (Though it hasn't the interpreter embedded at all!) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101713&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:20 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:20 -0700 Subject: [Patches] [Patch #101394] lookdict optimizations Message-ID: <200010181444.HAA14026@delerium.i.sourceforge.net> Patch #101394 has been updated. Project: Category: core (C code) Status: Open Summary: lookdict optimizations Follow-Ups: Date: 2000-Sep-03 21:09 By: marangoz Comment: Let's add a comment, although this has been raised on python-dev. This patch proposes a couple of ideas for optimizing & speeding dict lookups -- not all of them need to be applied though. - clear the eventual errors from Object_Compare only on need (this logic needs to be double-checked once again to see whether it really works) - defer variable initializations after the most common return cases - specialize string_compare() for lookdict_string. The test comparing the first char, before calling memcmp(), can be added too. - inline the first item probe in PyDict_GetItem. This saves a func call for the most common case (common to lookdict & lookdict_string). ------------------------------------------------------- Date: 2000-Sep-04 06:45 By: gvanrossum Comment: Quick comments: we should *always* call PyErr_Occurred() after PyObject_Compare() (and PyErr_Clear() if PyErr_Occurred() returned true). PyErr_Compare() really doesn't expect a pending exception coming in and so *not* clearing the error might break the *next* PyErr_Compare() call. (This doesn't happen typically but PyObject_Compare() can execute arbitrary code, some of which might call PyErr_Occurred() without calling PyErr_Clear() first.) ------------------------------------------------------- Date: 2000-Sep-05 06:05 By: none Comment: Correct! But then, aren't the current "else" if(cmp == 0) clauses risky after PyObject_Compare()? An exception may be set in external code while making Object_Compare() to return 0! Perhaps not in Python source, but in buggy extensions. lookdict() will then overlook this "hit". Patch updated, without "else" clauses and with the 1st char check in string_compare_equal(). ------------------------------------------------------- Date: 2000-Sep-05 06:08 By: marangoz Comment: Argh! These Web interfaces strike again - forgot to login. ------------------------------------------------------- Date: 2000-Sep-14 09:26 By: fdrake Comment: Revised patch: Instead of defining a function to do the fast string comparison, use a macro, but let it use the documented string object API (PyString_GET_SIZE(), PyString_AS_STRING()) instead of breaking the encapsulation in the code. This avoids all function calls to do the string compare, except memcmp() (which good compilers can inline anyway). Vladimir, take a look at this; if you're happy, I'm happy, and you can check it in. Thanks! ------------------------------------------------------- Date: 2000-Sep-14 13:51 By: fdrake Comment: Guido, please review (since Vladimir's away). ------------------------------------------------------- Date: 2000-Sep-15 11:18 By: gvanrossum Comment: Accepted. Assuming you've tested this, it looks fine to me. Can you time this a bit? There's one niggling issue: some people think that before you do memcmp() you should manually compare the first character. Others think that's unnecessary (since a good compiler can inline memcmp anyway). (It's also a bit scary if the size is zero.) So please ignore this but keep it in mind for timing experiments. :) ------------------------------------------------------- Date: 2000-Sep-25 14:38 By: twouters Comment: Shouldn't this patch be either postponed or checked in? ------------------------------------------------------- Date: 2000-Sep-25 18:52 By: fdrake Comment: It's postponed since I've not had time to run performance tests to measure the corner case it aims to improve. It turns out that generating the test data I need takes a long time (I need hash collisions of identifier-like strings). I just need to be able to let my generator run for a long time (it was generating more collisions than I'd expected, but I don't know how many off-hand). Another interesting metric would be to examine the .pyc files generated from the standard library and find out if there are any string hash collisions there -- if not, or if very few, it's not worth the added complexity. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101394&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:20 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:20 -0700 Subject: [Patches] [Patch #101394] lookdict optimizations Message-ID: <200010181444.HAA14027@delerium.i.sourceforge.net> Patch #101394 has been updated. Project: Category: core (C code) Status: Open Summary: lookdict optimizations Follow-Ups: Date: 2000-Sep-03 21:09 By: marangoz Comment: Let's add a comment, although this has been raised on python-dev. This patch proposes a couple of ideas for optimizing & speeding dict lookups -- not all of them need to be applied though. - clear the eventual errors from Object_Compare only on need (this logic needs to be double-checked once again to see whether it really works) - defer variable initializations after the most common return cases - specialize string_compare() for lookdict_string. The test comparing the first char, before calling memcmp(), can be added too. - inline the first item probe in PyDict_GetItem. This saves a func call for the most common case (common to lookdict & lookdict_string). ------------------------------------------------------- Date: 2000-Sep-04 06:45 By: gvanrossum Comment: Quick comments: we should *always* call PyErr_Occurred() after PyObject_Compare() (and PyErr_Clear() if PyErr_Occurred() returned true). PyErr_Compare() really doesn't expect a pending exception coming in and so *not* clearing the error might break the *next* PyErr_Compare() call. (This doesn't happen typically but PyObject_Compare() can execute arbitrary code, some of which might call PyErr_Occurred() without calling PyErr_Clear() first.) ------------------------------------------------------- Date: 2000-Sep-05 06:05 By: none Comment: Correct! But then, aren't the current "else" if(cmp == 0) clauses risky after PyObject_Compare()? An exception may be set in external code while making Object_Compare() to return 0! Perhaps not in Python source, but in buggy extensions. lookdict() will then overlook this "hit". Patch updated, without "else" clauses and with the 1st char check in string_compare_equal(). ------------------------------------------------------- Date: 2000-Sep-05 06:08 By: marangoz Comment: Argh! These Web interfaces strike again - forgot to login. ------------------------------------------------------- Date: 2000-Sep-14 09:26 By: fdrake Comment: Revised patch: Instead of defining a function to do the fast string comparison, use a macro, but let it use the documented string object API (PyString_GET_SIZE(), PyString_AS_STRING()) instead of breaking the encapsulation in the code. This avoids all function calls to do the string compare, except memcmp() (which good compilers can inline anyway). Vladimir, take a look at this; if you're happy, I'm happy, and you can check it in. Thanks! ------------------------------------------------------- Date: 2000-Sep-14 13:51 By: fdrake Comment: Guido, please review (since Vladimir's away). ------------------------------------------------------- Date: 2000-Sep-15 11:18 By: gvanrossum Comment: Accepted. Assuming you've tested this, it looks fine to me. Can you time this a bit? There's one niggling issue: some people think that before you do memcmp() you should manually compare the first character. Others think that's unnecessary (since a good compiler can inline memcmp anyway). (It's also a bit scary if the size is zero.) So please ignore this but keep it in mind for timing experiments. :) ------------------------------------------------------- Date: 2000-Sep-25 14:38 By: twouters Comment: Shouldn't this patch be either postponed or checked in? ------------------------------------------------------- Date: 2000-Sep-25 18:52 By: fdrake Comment: It's postponed since I've not had time to run performance tests to measure the corner case it aims to improve. It turns out that generating the test data I need takes a long time (I need hash collisions of identifier-like strings). I just need to be able to let my generator run for a long time (it was generating more collisions than I'd expected, but I don't know how many off-hand). Another interesting metric would be to examine the .pyc files generated from the standard library and find out if there are any string hash collisions there -- if not, or if very few, it's not worth the added complexity. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101394&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:14 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:14 -0700 Subject: [Patches] [Patch #101196] IPv6 patch against 2.0 CVS tree, as of 20000816 21:52 Message-ID: <200010181444.HAA14001@delerium.i.sourceforge.net> Patch #101196 has been updated. Project: Category: core (C code) Status: Open Summary: IPv6 patch against 2.0 CVS tree, as of 20000816 21:52 Follow-Ups: Date: 2000-Aug-16 05:59 By: itojun Comment: this is revised version of patch #101186 (now with my SourceForge accout... i'm not familiar with the system here, so forgive my possible mistake). 1.6b1 patch applied mostly clean to 2.0. It is confirmed that: - 1.6b1 + IPv6 patch works fine on NetBSD 1.4.2 + KAME, and NetBSD 1.5 - 1.6b1 + IPv6 patch works fine on NetBSD 1.4.2 (NOT an IPv6 ready machine) - 2.0 CVS tree + IPv6 patch works fine on NetBSD + KAME forgot to attach the following into the diff - so i attach it (README.v6) here as comment. I have submitted the patch for 1.5.1, 1.5.2 and 1.6b1, all hit a bad timing - bad luck. contact: core@kame.net, or itojun@kame.net --- IPv6-ready python 1.6 KAME Project $KAME: README.v6,v 1.9 2000/08/15 02:40:38 itojun Exp $ This patchkit enables python 1.6 to perform AF_INET6 socket operations. The only affected module is Modules/socketmodule.c. Modules/socketmodule.c In most cases, IPv6 address can be placed where IPv4 address fits. sockaddr sockaddr tuple is formatted as follows: IPv4: (host, port) IPv6: socket class methods always generate (host, port, flowinfo, scopeid). socket class methods will accept 2, 3, or 4 tuple (for backward compatibility). Compatibility warning: Some of the scripts assume that the sockaddr structure is 2 tuple, like: host, port = sock.getpeername() this will fail if you are connected to IPv6 node. socket.getaddrinfo(host, port [, family, socktype, proto, flags]) host: String or None port: String, Int or None family, socktype, proto, flags: Int, can be omitted Perform getaddrinfo(3). Returns List of the following 5 tuple: (family, socktype, proto, canonname, sockaddr) family: Int socktype: Int proto: Int canonname: String sockaddr: sockaddr (see above) See Lib/httplib.py for typical usage on the client side. socket.getnameinfo(sockaddr, flags) sockaddr: sockaddr flags: Int Perform getnameinfo(3). Returns the following 2 tuple: host: String, numeric or hostname depending on flgags port: String, numeric or portname depending on flgags socket.gethostbyname2(host, af) host: String af: Int Performs gethostbyname2(3). Returns numeric address representation for "host". socket.gethostbyaddr(addr) (behavior change if IPv6 support is compiled in) addr: String Performs gethostbyaddr(3). Returns string address representation for "addr". The function can take IPv6 numeric address as well. This behavior is not problematical, because - if you pass numeric "addr" parameter, we can always identify address family for it - return value is string address reprsentation, where IPv6 and IPv4 are not distinguishable. socket.bind(sa), socket.connect(sa) and others. (No behavior change, but be careful) See above for sockaddr format change. With Python "addr" portion of sockaddr (first element) can be string hostname. When the string hostname resolved to numeric address, it will obey address family of the socket (which was specified when socket.socket() was called). If you give some string that does not give matching address family, you will get some error. s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) # this is okay, if 'localhost' resolves to both IPv4/v6 s.connect('localhost', 80) # this is not okay, of course s.connect('::1', 80) # this is not okay, as v6only.kame.net will not resolve to IPv4 s.connect('v6only.kame.net', 80) Lib/httplib.py IPv6 ready. "host" in HTTP(host) will accept the following 3 forms: [host]:port host:port there must be only single colon host This is to allow IPv6 numeric URL (http://[host]:port/) in documents. IMHO "host:port" parsing should be implemented in urllib.py, not here. Lib/ftplib.py IPv6 ready. This uses EPSV/EPRT on IPv6 ftp. See RFC2428 for protocol details. Lib/SocketServer.py IPv6 ready. Wildcard bind on TCPServer, i.e. TCPServer(('', port)), will bind to wildcard socket on TCPServer.address_family. TCPServer.addresss_family is set to AF_INET by default, so ('', port) will usually bind AF_INET. Lib/smtplib.py, Lib/telnetlib.py, Lib/poplib.py IPv6 ready. Not much to say about protocol details - they just use TCP over IPv6. configure Configure has extra option, --enable-ipv6 and --disable-ipv6. The option controls IPv6 support feature. dynamic link issues in Modules/socketmodule.c Modules/socketmodule.c can be dynamically loaded only in the following situations: - getaddrinfo(3) and getnameinfo(3) are supplied by OS vendor in libc, and libc is dynamic link library. - OS vendor is NOT supplying getaddrinfo(3) nor getnameinfo(3), and You are configuring this package with --disable-ipv6. In this case, you'll be using missing/get{addr,name}info.c and they will refer to gethostby{name,addr}. gethostnameby{name,addr} can usually be found in dynamic-linking libc. In other situations, such as the following, please link Modules/socketmodule.c into python itself. - getaddrinfo(3) and getnameinfo(3) are supplied by OS vendor, but they are in statically linked library like libinet6.a. (KAME falls into this category) python usually links Modules/socketmodule.c into python itself (due to its popularity) so there should be no problem. restrictions - The patched tree will not use gethostbyname_r and other thread-ready libraries. Instead, it will use getaddrinfo() and getnameinfo() throughout the operation. todo - Patch bunch of library files in Lib/*.py. compatibility issues with existing scripts If you disable IPv6 support (./configure --disable-ipv6), the patched code is mostly compatible with original Python (except files in "Lib" directory modified for dual stack support). User script may choke if: - IPv4/v6 dualstack libc is supplied, python is compiled for dual stack, and script assumes some of IPv4-only behavior (especially sockaddr) - IPv4/v6 dualstack libc is supplied, python is compiled for IPv4 only, and script assumes some of IPv4-only behavior. In this case, Python socket class itself does not support IPv6, however, name resolution functions can return IPv6 names since they use IPv6-ready libc functions! I do not recommend this configuration. - script assumes certain IPv4-only version behavior in Lib/*.py. compilation If you use IPv6 features, it is assumed that you have working getaddrinfo() and getnameinfo() library functions. We have noticed that some of IPv6 stack is shipped with broken getaddrinfo(). In such cases, use missing/get{addr,name}info.c instead (but then, you need to have working getipnodeby{name,addr}). If you compile this on IPv4-only machine without get{addr,name}info, missing/get{addr,name}info.c will be used. They are from KAME IPv6 distribution and is #ifdef'ed for IPv4 only support. They are fairly complete implementation and you don't need to bother with bind 8.2 (bind 8.2 get{addr,name}info() has bugs). When compiling this kit on IPv6 node, you may need to specify some additional library paths or cpp defs. (like -linet6 or -DINET6) --enable-ipv6 will give you some warning, if the IPv6 stack is unknown to the "configure" script. Currently, the following IPv6 stacks are officially supported (i.e. we've checked that the package works well): - KAME IPv6 stack, http://www.kame.net/ References RFC2553, for getaddrinfo(3) and getnameinfo(3). Author contacts http://www.kame.net/ mailto:core@kame.net ------------------------------------------------------- Date: 2000-Aug-16 06:07 By: moshez Comment: Assigned to Tim, since he's in charge of postponing new features. I'm to timid to postpone it myself. ------------------------------------------------------- Date: 2000-Aug-16 07:00 By: fdrake Comment: Postponed until Python 2.1 -- there's not enough time to review this and get it sufficiently tested on enough IPv6-connected platforms in time for 2.0, and we're already in feature freeze. This should go into the tree very quickly once Python 2.0 has been released. Assigned to myself to open it back up after Python 2.0. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101196&group_id=5470 From noreply@sourceforge.net Wed Oct 18 15:44:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 07:44:03 -0700 Subject: [Patches] [Patch #100902] range-literals, not relative to listcomprehensions Message-ID: <200010181444.HAA13971@delerium.i.sourceforge.net> Patch #100902 has been updated. Project: Category: core (C code) Status: Open Summary: range-literals, not relative to listcomprehensions Follow-Ups: Date: 2000-Jul-15 16:31 By: twouters Comment: A new version of the patch that adds range-literals ([0:20], [:33:2], etc), this time not relative to list-comprehensions. I marked the previous one 'Out of Date'. I'm still working on the PEP, but I think the patch is done ;-) ------------------------------------------------------- Date: 2000-Jul-18 08:25 By: twouters Comment: Someone needs to check this patch out, and tell me whether Guido really meant 'check it in' by his 'Right!' in http://www.python.org/pipermail/python-dev/2000-July/013234.html Tim, you seem like the perfect person, especially now you're sharing half a room with Guido ;) ------------------------------------------------------- Date: 2000-Jul-22 15:04 By: tim_one Comment: Mostly adding a comment to see whether SourceForge generates patches-list email. From a quick scan, please update the patch so that new functions are already ANSIfied. This also needs doc changes. ------------------------------------------------------- Date: 2000-Jul-23 06:23 By: twouters Comment: New version of patch, ANSIfied and all. Documentation, uh, comes later. Promise ;) ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-15 11:49 By: tim_one Comment: Tim, get off your fat ass and review this! Umm, OK. Thomas, we need the doc changes Soon or I'll have to postpone this. Guido already likes the idea, so there's nothing to stop this from getting accepted except a complete patch (and, ya, getting that fat-ass Tim to actually review it!). ------------------------------------------------------- Date: 2000-Aug-15 14:08 By: twouters Comment: Here are the doc changes. Not much, I'm afraid, because I'm not sure where or how to insert them, assides from where I added them now (that being the reference manual.) I can write a bit of text for the tutorial, if that's desired, but I'll need some hints as to where, how long, in what style, and how this 'TeX' thing works. ------------------------------------------------------- Date: 2000-Aug-15 14:32 By: tim_one Comment: Great! Please work directly with Fred Drake on doc issues. Keep your docs simple plain ASCII and he's a whiz at adding the TeX bit later. And when he's happy with the docs, everyone is. ------------------------------------------------------- Date: 2000-Aug-22 09:13 By: twouters Comment: New version, one that actually includes the minimal docs I wrote :-) Also up to date wrt. the latest Grammar changes and such. ------------------------------------------------------- Date: 2000-Aug-27 12:28 By: tim_one Comment: Thomas, could you please update this patch? Running patch on Windows is always an adventure, so I had Guido check that this fails for him too on import.c (probably just the magic number) and ref5.tex. Guido also reports that his patch rejected the graminit.h change, but mine didn't (I'm guessing he modified his graminit.h locally, though; mine is straight from CVS). Thanks! ------------------------------------------------------- Date: 2000-Aug-27 14:04 By: twouters Comment: Alright, here's an updated version. I also included graminit.h and .c, because I don't know if you can run pgen, and if you complain about graminit.h not patching, I guess you can't ;-) (the fact that graminit.h was included in the previous patch was an honest mistake. But if you intend to read this patch: there's nothing interesting below graminit.c, which is about 900 lines.) ------------------------------------------------------- Date: 2000-Aug-28 00:31 By: tim_one Comment: Assigned to Fred to eyeball the docs; assign back to me if you're happy, else to Thomas if you're not. Thomas, this looks good! I have a nit and a complaint. The nit is that we don't need to keep bumping import's magic number -- once per public release should be enough. The complaint is that PyList_GetLenOfRange is brittle. In the context the code originally appeared, it was file-private, so all call sites were known and close by, that its assumptions were met was easy to verify, and that it did only 48% of the job didn't matter. But here it's almost part of the public API: it should do the whole job. By that I mean it should verify that its step argument is non-zero, and if the step argument is less than 0 it should shuffle the input values around to compute the correct answer. As is, this delicate shuffling is duplicated in its callers, and if someone happens to pass in a step < 0 it's just hosed. I would prefer: 1. Rename it with a leading underscore. This doesn't seem useful enough to be in the public API. 2. If it's private, it's OK to assert argument preconditions instead of error-checking them. So stick in assert(size != 0). 3. Deal with negative step size internally. Like (leading x to stop SourceForge from left-flushing all the lines): if (step < 0) { x long temp = lo; x lo = hi; x hi = temp; x step = -step; } right after the new assert. 4. Remove the if/else argument swapping from all its callers. 5. Change the comment before the function to match. ------------------------------------------------------- Date: 2000-Aug-28 01:02 By: twouters Comment: Okay, but I have one question: WTH do you mean by '2.' ? assert what size ? the return value of getlenofrange ? all those values are passed-in, from Python expressions, so I don't think assert()in them is that good an idea. I really doubt you want the program to abort() if a user types in '[:0:]' or some such. Oh, and on the nit: I still don't agree, see my other comment in, uhm, some patch or other: we aren't using up a scarce resource with the MAGIC, as it's created by date, and it prevents *new* bytecode from running in *old* (relatively) interpreters, even if those old interpreters are only a few days old and the whole thing would 'only' happen to other developers. Or is there something else I don't know about ? ------------------------------------------------------- Date: 2000-Aug-28 01:32 By: tim_one Comment: Ack, 'twas a typo, I meant assert(step != 0); It's an *internal* (not user!) error if anyone calls this function with a zero step, so the function should at least assert that its caller isn't screwing up. The advantage to an assert over SystemError is simplicity and that there's no runtime cost in release builds. C functions should always verify their preconditions in debug builds, and public C functions regardless of build mode. The magic number isn't worth arguing about it -- leave it in, take it out, both OK by me (that's what "nit" means ). I always delete my .pyc/.pyo files after an update changes anything; I assume everyone does. ------------------------------------------------------- Date: 2000-Aug-28 13:30 By: twouters Comment: Ok, bettah version, that should address all Tim's issues. And I dropped the Upping of the ByteCodeMagic too. ------------------------------------------------------- Date: 2000-Aug-28 13:53 By: gvanrossum Comment: Oops. Sorry. I'm getting second thoughts about this. I'll post to python-dev. ------------------------------------------------------- Date: 2000-Aug-28 21:32 By: tim_one Comment: Assigned to Guido. Please Reject or assign back to me (I quickly scanned Thomas's changes, and *think* they're spot-on, but if this is going in I want to spend a little more time with the patch before Accept'ing it). ------------------------------------------------------- Date: 2000-Aug-29 07:53 By: gvanrossum Comment: Postponed - this may still happen but definitely not in 2.0, there's too much doubt about whether this is the right syntax and too many alternative proposals that have to be reviewed. (Well, at least one. :-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100902&group_id=5470 From noreply@sourceforge.net Wed Oct 18 21:53:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 13:53:18 -0700 Subject: [Patches] [Patch #101970] Allow urllib to support http: Message-ID: <200010182053.NAA29748@delerium.i.sourceforge.net> Patch #101970 has been updated. Project: Category: library Status: Open Summary: Allow urllib to support http: ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101970&group_id=5470 From noreply@sourceforge.net Wed Oct 18 23:50:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 15:50:39 -0700 Subject: [Patches] [Patch #101972] Fix for lookbehind bug (#117242) Message-ID: <200010182250.PAA31073@bush.i.sourceforge.net> Patch #101972 has been updated. Project: Category: library Status: Open Summary: Fix for lookbehind bug (#117242) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101972&group_id=5470 From noreply@sourceforge.net Wed Oct 18 23:51:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 15:51:29 -0700 Subject: [Patches] [Patch #101972] Fix for lookbehind bug (#117242) Message-ID: <200010182251.PAA31122@bush.i.sourceforge.net> Patch #101972 has been updated. Project: Category: library Status: Open Summary: Fix for lookbehind bug (#117242) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101972&group_id=5470 From noreply@sourceforge.net Thu Oct 19 00:37:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 16:37:57 -0700 Subject: [Patches] [Patch #101973] test_import.py fails on Unix when run any but the local dir Message-ID: <200010182337.QAA00489@bush.i.sourceforge.net> Patch #101973 has been updated. Project: Category: library Status: Open Summary: test_import.py fails on Unix when run any but the local dir ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101973&group_id=5470 From noreply@sourceforge.net Thu Oct 19 00:40:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 16:40:18 -0700 Subject: [Patches] [Patch #101973] test_import.py fails on Unix when run any but the local dir Message-ID: <200010182340.QAA00583@bush.i.sourceforge.net> Patch #101973 has been updated. Project: Category: library Status: Open Summary: test_import.py fails on Unix when run any but the local dir Follow-Ups: Date: 2000-Oct-18 16:40 By: tmick Comment: Make test_import.py pass when it is invoked as follows: > ./python Lib/test/test_import.py or > ./python Lib/test/regrtest.py test_import I.e. from any dir other that where test_import.py exists. The problem was that on Unix, if a relative path to a script is given on the command line, that path is added to sys.path and *not* the current directory. That is fine, except that test_import.py presumed that the current directory (in which @TESTFN.py is created) is on sys.path. Solution: Put the current working dir on sys.path. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101973&group_id=5470 From noreply@sourceforge.net Thu Oct 19 00:41:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 16:41:01 -0700 Subject: [Patches] [Patch #101973] test_import.py fails on Unix when run any but the local dir Message-ID: <200010182341.QAA00586@bush.i.sourceforge.net> Patch #101973 has been updated. Project: Category: library Status: Open Summary: test_import.py fails on Unix when run any but the local dir Follow-Ups: Date: 2000-Oct-18 16:40 By: tmick Comment: Make test_import.py pass when it is invoked as follows: > ./python Lib/test/test_import.py or > ./python Lib/test/regrtest.py test_import I.e. from any dir other that where test_import.py exists. The problem was that on Unix, if a relative path to a script is given on the command line, that path is added to sys.path and *not* the current directory. That is fine, except that test_import.py presumed that the current directory (in which @TESTFN.py is created) is on sys.path. Solution: Put the current working dir on sys.path. ------------------------------------------------------- Date: 2000-Oct-18 16:41 By: tmick Comment: TIm's checkin said that this was your module Jeremy so I am assigning to you for review. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101973&group_id=5470 From noreply@sourceforge.net Thu Oct 19 02:19:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 18:19:36 -0700 Subject: [Patches] [Patch #101970] Allow urllib to support http: Message-ID: <200010190119.SAA07651@delerium.i.sourceforge.net> Patch #101970 has been updated. Project: Category: library Status: Open Summary: Allow urllib to support http: ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101970&group_id=5470 From noreply@sourceforge.net Thu Oct 19 07:09:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 23:09:09 -0700 Subject: [Patches] [Patch #101973] test_import.py fails on Unix when run any but the local dir Message-ID: <200010190609.XAA14752@bush.i.sourceforge.net> Patch #101973 has been updated. Project: Category: library Status: Open Summary: test_import.py fails on Unix when run any but the local dir Follow-Ups: Date: 2000-Oct-18 16:40 By: tmick Comment: Make test_import.py pass when it is invoked as follows: > ./python Lib/test/test_import.py or > ./python Lib/test/regrtest.py test_import I.e. from any dir other that where test_import.py exists. The problem was that on Unix, if a relative path to a script is given on the command line, that path is added to sys.path and *not* the current directory. That is fine, except that test_import.py presumed that the current directory (in which @TESTFN.py is created) is on sys.path. Solution: Put the current working dir on sys.path. ------------------------------------------------------- Date: 2000-Oct-18 16:41 By: tmick Comment: TIm's checkin said that this was your module Jeremy so I am assigning to you for review. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101973&group_id=5470 From noreply@sourceforge.net Thu Oct 19 07:10:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 23:10:23 -0700 Subject: [Patches] [Patch #101973] test_import.py fails on Unix when run any but the local dir Message-ID: <200010190610.XAA14776@bush.i.sourceforge.net> Patch #101973 has been updated. Project: Category: library Status: Open Summary: test_import.py fails on Unix when run any but the local dir Follow-Ups: Date: 2000-Oct-18 16:40 By: tmick Comment: Make test_import.py pass when it is invoked as follows: > ./python Lib/test/test_import.py or > ./python Lib/test/regrtest.py test_import I.e. from any dir other that where test_import.py exists. The problem was that on Unix, if a relative path to a script is given on the command line, that path is added to sys.path and *not* the current directory. That is fine, except that test_import.py presumed that the current directory (in which @TESTFN.py is created) is on sys.path. Solution: Put the current working dir on sys.path. ------------------------------------------------------- Date: 2000-Oct-18 16:41 By: tmick Comment: TIm's checkin said that this was your module Jeremy so I am assigning to you for review. ------------------------------------------------------- Date: 2000-Oct-18 23:10 By: tmick Comment: a comment from Neil: I disagree. The test suite should not assume write access to the current directory. It should probably create a temparary directory using mktemp() or similar, add that to sys.path and create files there. Sorry about not using SF but I'm on a 14.4k modem. :( Neil ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101973&group_id=5470 From noreply@sourceforge.net Thu Oct 19 07:19:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Oct 2000 23:19:40 -0700 Subject: [Patches] [Patch #101973] test_import.py fails on Unix when run any but the local dir Message-ID: <200010190619.XAA18476@delerium.i.sourceforge.net> Patch #101973 has been updated. Project: Category: library Status: Open Summary: test_import.py fails on Unix when run any but the local dir Follow-Ups: Date: 2000-Oct-18 16:40 By: tmick Comment: Make test_import.py pass when it is invoked as follows: > ./python Lib/test/test_import.py or > ./python Lib/test/regrtest.py test_import I.e. from any dir other that where test_import.py exists. The problem was that on Unix, if a relative path to a script is given on the command line, that path is added to sys.path and *not* the current directory. That is fine, except that test_import.py presumed that the current directory (in which @TESTFN.py is created) is on sys.path. Solution: Put the current working dir on sys.path. ------------------------------------------------------- Date: 2000-Oct-18 16:41 By: tmick Comment: TIm's checkin said that this was your module Jeremy so I am assigning to you for review. ------------------------------------------------------- Date: 2000-Oct-18 23:10 By: tmick Comment: a comment from Neil: I disagree. The test suite should not assume write access to the current directory. It should probably create a temparary directory using mktemp() or similar, add that to sys.path and create files there. Sorry about not using SF but I'm on a 14.4k modem. :( Neil ------------------------------------------------------- Date: 2000-Oct-18 23:19 By: tmick Comment: Yes, I guess I agree. Frankly *every* use of test_support.TESTFN in the test suite should be replaced with the use of tempfile.mktemp(). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101973&group_id=5470 From noreply@sourceforge.net Thu Oct 19 21:54:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Oct 2000 13:54:28 -0700 Subject: [Patches] [Patch #101980] Fix for #117278: check for null pointers in Tcl decref Message-ID: <200010192054.NAA10521@bush.i.sourceforge.net> Patch #101980 has been updated. Project: Category: Tkinter Status: Open Summary: Fix for #117278: check for null pointers in Tcl decref ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101980&group_id=5470 From noreply@sourceforge.net Thu Oct 19 22:06:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Oct 2000 14:06:04 -0700 Subject: [Patches] [Patch #101980] Fix for #117278: Do not release unallocated Tcl objects Message-ID: <200010192106.OAA11098@bush.i.sourceforge.net> Patch #101980 has been updated. Project: Category: Tkinter Status: Open Summary: Fix for #117278: Do not release unallocated Tcl objects Follow-Ups: Date: 2000-Oct-19 14:06 By: loewis Comment: Tcl's decref does not check for null pointers. This patch releases only successfully allocated objects. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101980&group_id=5470 From noreply@sourceforge.net Fri Oct 20 04:23:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Oct 2000 20:23:29 -0700 Subject: [Patches] [Patch #101980] Fix for #117278: Do not release unallocated Tcl objects Message-ID: <200010200323.UAA27879@delerium.i.sourceforge.net> Patch #101980 has been updated. Project: Category: Tkinter Status: Open Summary: Fix for #117278: Do not release unallocated Tcl objects Follow-Ups: Date: 2000-Oct-19 14:06 By: loewis Comment: Tcl's decref does not check for null pointers. This patch releases only successfully allocated objects. ------------------------------------------------------- Date: 2000-Oct-19 20:23 By: fdrake Comment: Slightly simplified the patch, and avoid setting objc to zero twice when no intervening value was possible. Martin, if you're happy this change, go ahead and check it in and close the associated bug report. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101980&group_id=5470 From noreply@sourceforge.net Fri Oct 20 04:29:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Oct 2000 20:29:39 -0700 Subject: [Patches] [Patch #101782] Enhances 1.6 compiler to raise 'proper' SyntaxErrors Message-ID: <200010200329.UAA28101@delerium.i.sourceforge.net> Patch #101782 has been updated. Project: Category: Parser/Compiler Status: Open Summary: Enhances 1.6 compiler to raise 'proper' SyntaxErrors Follow-Ups: Date: 2000-Oct-04 12:29 By: Roman_Sulzhyk Comment: Hello: There's a problem with the compiler.c (which persists in 2.0 also) which means it raises 'old style' SyntaxErrors, which could not be formatted properly. I mentioned this to Guido during the last conference, and he said it can best be done by moving parts of the 'linecache' functionality to core python, or something along those lines. Well, I've put together something which is not so far-fetching, but plugs this hole. The only time it reverts to the 'old style' compile error is when the input file is not a regular file (like stdin), since the line information is lost at that point - don't think parser.c saves it anywhere. Tell me what you think - should I port it to 2.0, or just drop it altogether if it's not needed. Thanks, Roman ------------------------------------------------------- Date: 2000-Oct-04 23:40 By: fdrake Comment: This needs to be ported to the latest CVS version before being considered for implementation (but discussion of the feature is welcome!). This cannot be considered for inclusion in 2.0 since we're in feature freeze already, and are only fixing bugs at this point. This can be considered for 2.1. Marking as postponed. ------------------------------------------------------- Date: 2000-Oct-09 10:59 By: Roman_Sulzhyk Comment: I've ported it to the latest CVS version - check it out, Roman ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101782&group_id=5470 From noreply@sourceforge.net Fri Oct 20 04:33:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Oct 2000 20:33:05 -0700 Subject: [Patches] [Patch #101839] better error messages Message-ID: <200010200333.UAA28268@delerium.i.sourceforge.net> Patch #101839 has been updated. Project: Category: core (C code) Status: Open Summary: better error messages Follow-Ups: Date: 2000-Oct-08 20:20 By: ping Comment: This patch tries to make the feedback from error messages more consistent and helpful. For example: >>> os.kf Traceback (most recent call last): File "", line 1, in ? AttributeError: 'os' module has no attribute 'kf' >>> int(a=3) Traceback (most recent call last): File "", line 1, in ? TypeError: int() takes no keyword arguments >>> class Foo: pass ... >>> Foo.spam Traceback (most recent call last): File "", line 1, in ? AttributeError: class Foo has no attribute 'spam' >>> Foo().spam Traceback (most recent call last): File "", line 1, in ? AttributeError: Foo instance has no attribute 'spam' >>> Foo()() Traceback (most recent call last): File "", line 1, in ? AttributeError: Foo instance has no __call__ method This isn't really a bug, but it's not a feature either. I wanted to get it in before the Monday freeze. If you have time, have a look; i'll leave it to your judgement whether it's okay to check in. I know it's close to the wire, but it's effectively small: there are no changes in logic, only strings edited here and there. The corresponding changes to the tests that relied on specific wording of error messages are also included. ------------------------------------------------------- Date: 2000-Oct-08 20:26 By: ping Comment: More examples: >>> import os >>> del os.kf Traceback (most recent call last): File "", line 1, in ? AttributeError: 'os' module has no attribute 'kf' >>> pow(3,4,0) Traceback (most recent call last): File "", line 1, in ? ValueError: pow() arg 3 cannot be 0 >>> os.execv('a', 3) Traceback (most recent call last): File "", line 1, in ? TypeError: execv() arg 2 must be a tuple or list >>> os.execv('a', (3,4)) Traceback (most recent call last): File "", line 1, in ? TypeError: execv() arg 2 must contain only strings >>> 0 ** -4 Traceback (most recent call last): File "", line 1, in ? ZeroDivisionError: cannot raise 0 to a negative power >>> int("45", 1) Traceback (most recent call last): File "", line 1, in ? ValueError: int() base must be >= 2 and <= 36 >>> ord(3) Traceback (most recent call last): File "", line 1, in ? TypeError: ord() expected string or Unicode character, int found ------------------------------------------------------- Date: 2000-Oct-08 20:28 By: ping Comment: Forgot to mention that this patch also includes changed names for audio formats in the linuxaudiodev module. ------------------------------------------------------- Date: 2000-Oct-09 05:32 By: gvanrossum Comment: Sorry, but this has to go in after 2.0 final is released. It's touching way too much code to be snuck in at the very last moment. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101839&group_id=5470 From loewis@informatik.hu-berlin.de Fri Oct 20 16:24:17 2000 From: loewis@informatik.hu-berlin.de (Martin von Loewis) Date: Fri, 20 Oct 2000 17:24:17 +0200 (MET DST) Subject: [Patches] Re: [Patch #101980] Fix for #117278: Do not release unallocated Tcl objects In-Reply-To: <200010200323.UAA27879@delerium.i.sourceforge.net> (noreply@sourceforge.net) References: <200010200323.UAA27879@delerium.i.sourceforge.net> Message-ID: <200010201524.RAA08801@pandora.informatik.hu-berlin.de> > Martin, if you're happy this change, go ahead and check it in and > close the associated bug report. The question is: Can I, and should I commit it to the release branch (2.0) as well? Martin From noreply@sourceforge.net Fri Oct 20 20:41:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Oct 2000 12:41:47 -0700 Subject: [Patches] [Patch #101993] Fix prepare_input_stream bug Message-ID: <200010201941.MAA27767@delerium.i.sourceforge.net> Patch #101993 has been updated. Project: Category: XML Status: Open Summary: Fix prepare_input_stream bug ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101993&group_id=5470 From noreply@sourceforge.net Fri Oct 20 20:42:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Oct 2000 12:42:21 -0700 Subject: [Patches] [Patch #101993] Fix prepare_input_stream bug Message-ID: <200010201942.MAA27798@delerium.i.sourceforge.net> Patch #101993 has been updated. Project: Category: XML Status: Open Summary: Fix prepare_input_stream bug ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101993&group_id=5470 From noreply@sourceforge.net Mon Oct 23 04:55:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Oct 2000 20:55:44 -0700 Subject: [Patches] [Patch #102075] More DOM documentation Message-ID: <200010230355.UAA09206@sf-web1.i.sourceforge.net> Patch #102075 has been updated. Project: Category: XML Status: Open Summary: More DOM documentation ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102075&group_id=5470 From noreply@sourceforge.net Mon Oct 23 05:16:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Oct 2000 21:16:43 -0700 Subject: [Patches] [Patch #102075] More DOM documentation Message-ID: <200010230416.VAA06317@sf-web3.vaspecialprojects.com> Patch #102075 has been updated. Project: Category: documentation Status: Open Summary: More DOM documentation ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102075&group_id=5470 From noreply@sourceforge.net Mon Oct 23 09:37:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Oct 2000 01:37:11 -0700 Subject: [Patches] [Patch #101993] Fix prepare_input_stream bug Message-ID: <200010230837.BAA12792@sf-web1.i.sourceforge.net> Patch #101993 has been updated. Project: Category: XML Status: Accepted Summary: Fix prepare_input_stream bug ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101993&group_id=5470 From noreply@sourceforge.net Mon Oct 23 14:22:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Oct 2000 06:22:58 -0700 Subject: [Patches] [Patch #102068] fix for bug #117402 (repr of array) Message-ID: <200010231322.GAA12926@sf-web2.i.sourceforge.net> Patch #102068 has been updated. Project: Category: Modules Status: Open Summary: fix for bug #117402 (repr of array) Follow-Ups: Date: 2000-Oct-22 09:51 By: mwh Comment: before: >>> import array >>> array.array('c',"cd") array('c', 'cd') >>> repr(_) Segmentation fault (core dumped) after: >>> import array >>> array.array('c',"dd") array('c', 'dd') >>> `_` "array('c', 'dd')" Fixes bug #117402, which was introduced in revision 2.51. ------------------------------------------------------- Date: 2000-Oct-23 06:22 By: nascheme Comment: A test case should be added to make sure str() and repr() work on arrays. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102068&group_id=5470 From noreply@sourceforge.net Mon Oct 23 20:19:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Oct 2000 12:19:17 -0700 Subject: [Patches] [Patch #100902] range-literals, not relative to listcomprehensions Message-ID: <200010231919.MAA20273@sf-web3.vaspecialprojects.com> Patch #100902 has been updated. Project: Category: core (C code) Status: Rejected Summary: range-literals, not relative to listcomprehensions Follow-Ups: Date: 2000-Jul-15 16:31 By: twouters Comment: A new version of the patch that adds range-literals ([0:20], [:33:2], etc), this time not relative to list-comprehensions. I marked the previous one 'Out of Date'. I'm still working on the PEP, but I think the patch is done ;-) ------------------------------------------------------- Date: 2000-Jul-18 08:25 By: twouters Comment: Someone needs to check this patch out, and tell me whether Guido really meant 'check it in' by his 'Right!' in http://www.python.org/pipermail/python-dev/2000-July/013234.html Tim, you seem like the perfect person, especially now you're sharing half a room with Guido ;) ------------------------------------------------------- Date: 2000-Jul-22 15:04 By: tim_one Comment: Mostly adding a comment to see whether SourceForge generates patches-list email. From a quick scan, please update the patch so that new functions are already ANSIfied. This also needs doc changes. ------------------------------------------------------- Date: 2000-Jul-23 06:23 By: twouters Comment: New version of patch, ANSIfied and all. Documentation, uh, comes later. Promise ;) ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-13 10:45 By: twouters Comment: Up-to-date version, which thus is again relative to list comprehensions, since they are checked in :-) Working on documentation, will be added later. ------------------------------------------------------- Date: 2000-Aug-15 11:49 By: tim_one Comment: Tim, get off your fat ass and review this! Umm, OK. Thomas, we need the doc changes Soon or I'll have to postpone this. Guido already likes the idea, so there's nothing to stop this from getting accepted except a complete patch (and, ya, getting that fat-ass Tim to actually review it!). ------------------------------------------------------- Date: 2000-Aug-15 14:08 By: twouters Comment: Here are the doc changes. Not much, I'm afraid, because I'm not sure where or how to insert them, assides from where I added them now (that being the reference manual.) I can write a bit of text for the tutorial, if that's desired, but I'll need some hints as to where, how long, in what style, and how this 'TeX' thing works. ------------------------------------------------------- Date: 2000-Aug-15 14:32 By: tim_one Comment: Great! Please work directly with Fred Drake on doc issues. Keep your docs simple plain ASCII and he's a whiz at adding the TeX bit later. And when he's happy with the docs, everyone is. ------------------------------------------------------- Date: 2000-Aug-22 09:13 By: twouters Comment: New version, one that actually includes the minimal docs I wrote :-) Also up to date wrt. the latest Grammar changes and such. ------------------------------------------------------- Date: 2000-Aug-27 12:28 By: tim_one Comment: Thomas, could you please update this patch? Running patch on Windows is always an adventure, so I had Guido check that this fails for him too on import.c (probably just the magic number) and ref5.tex. Guido also reports that his patch rejected the graminit.h change, but mine didn't (I'm guessing he modified his graminit.h locally, though; mine is straight from CVS). Thanks! ------------------------------------------------------- Date: 2000-Aug-27 14:04 By: twouters Comment: Alright, here's an updated version. I also included graminit.h and .c, because I don't know if you can run pgen, and if you complain about graminit.h not patching, I guess you can't ;-) (the fact that graminit.h was included in the previous patch was an honest mistake. But if you intend to read this patch: there's nothing interesting below graminit.c, which is about 900 lines.) ------------------------------------------------------- Date: 2000-Aug-28 00:31 By: tim_one Comment: Assigned to Fred to eyeball the docs; assign back to me if you're happy, else to Thomas if you're not. Thomas, this looks good! I have a nit and a complaint. The nit is that we don't need to keep bumping import's magic number -- once per public release should be enough. The complaint is that PyList_GetLenOfRange is brittle. In the context the code originally appeared, it was file-private, so all call sites were known and close by, that its assumptions were met was easy to verify, and that it did only 48% of the job didn't matter. But here it's almost part of the public API: it should do the whole job. By that I mean it should verify that its step argument is non-zero, and if the step argument is less than 0 it should shuffle the input values around to compute the correct answer. As is, this delicate shuffling is duplicated in its callers, and if someone happens to pass in a step < 0 it's just hosed. I would prefer: 1. Rename it with a leading underscore. This doesn't seem useful enough to be in the public API. 2. If it's private, it's OK to assert argument preconditions instead of error-checking them. So stick in assert(size != 0). 3. Deal with negative step size internally. Like (leading x to stop SourceForge from left-flushing all the lines): if (step < 0) { x long temp = lo; x lo = hi; x hi = temp; x step = -step; } right after the new assert. 4. Remove the if/else argument swapping from all its callers. 5. Change the comment before the function to match. ------------------------------------------------------- Date: 2000-Aug-28 01:02 By: twouters Comment: Okay, but I have one question: WTH do you mean by '2.' ? assert what size ? the return value of getlenofrange ? all those values are passed-in, from Python expressions, so I don't think assert()in them is that good an idea. I really doubt you want the program to abort() if a user types in '[:0:]' or some such. Oh, and on the nit: I still don't agree, see my other comment in, uhm, some patch or other: we aren't using up a scarce resource with the MAGIC, as it's created by date, and it prevents *new* bytecode from running in *old* (relatively) interpreters, even if those old interpreters are only a few days old and the whole thing would 'only' happen to other developers. Or is there something else I don't know about ? ------------------------------------------------------- Date: 2000-Aug-28 01:32 By: tim_one Comment: Ack, 'twas a typo, I meant assert(step != 0); It's an *internal* (not user!) error if anyone calls this function with a zero step, so the function should at least assert that its caller isn't screwing up. The advantage to an assert over SystemError is simplicity and that there's no runtime cost in release builds. C functions should always verify their preconditions in debug builds, and public C functions regardless of build mode. The magic number isn't worth arguing about it -- leave it in, take it out, both OK by me (that's what "nit" means ). I always delete my .pyc/.pyo files after an update changes anything; I assume everyone does. ------------------------------------------------------- Date: 2000-Aug-28 13:30 By: twouters Comment: Ok, bettah version, that should address all Tim's issues. And I dropped the Upping of the ByteCodeMagic too. ------------------------------------------------------- Date: 2000-Aug-28 13:53 By: gvanrossum Comment: Oops. Sorry. I'm getting second thoughts about this. I'll post to python-dev. ------------------------------------------------------- Date: 2000-Aug-28 21:32 By: tim_one Comment: Assigned to Guido. Please Reject or assign back to me (I quickly scanned Thomas's changes, and *think* they're spot-on, but if this is going in I want to spend a little more time with the patch before Accept'ing it). ------------------------------------------------------- Date: 2000-Aug-29 07:53 By: gvanrossum Comment: Postponed - this may still happen but definitely not in 2.0, there's too much doubt about whether this is the right syntax and too many alternative proposals that have to be reviewed. (Well, at least one. :-) ------------------------------------------------------- Date: 2000-Oct-23 12:19 By: gvanrossum Comment: Rejected -- I think I don't like this very much any more. Sorry Thomas! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100902&group_id=5470 From noreply@sourceforge.net Mon Oct 23 20:33:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Oct 2000 12:33:01 -0700 Subject: [Patches] [Patch #101702] Modify co_filename in frozen programs Message-ID: <200010231933.MAA24042@sf-web1.i.sourceforge.net> Patch #101702 has been updated. Project: Category: demos and tools Status: Open Summary: Modify co_filename in frozen programs Follow-Ups: Date: 2000-Sep-29 04:39 By: lhudson Comment: A new feature for freeze. This patch was developed primarily to reduce the size of the frozen binary. It is particularly useful when freezing for 'small' platforms, such as Palm OS, where you really want to save that last miserable byte. A limitation of this patch is that it does not provide any feedback about the replacements being made. As the path matching is case-sensitive this may lead to unexpected behaviour for DOS and Windows people, eg > freeze.py -r C:\Python\Lib\=py\ goats.py should probably be: > freeze.py -r c:\python\lib\=py\ goats.py ------------------------------------------------------- Date: 2000-Sep-29 07:28 By: jhylton Comment: This sounds like a reasonable enough feature, but we are in feature freeze for Python 2.0. ------------------------------------------------------- Date: 2000-Oct-23 12:33 By: gvanrossum Comment: I like the idea, but I have a few suggestions. - To avoid the case sensitivity issue you mention, you could use os.path.normpath() before the string comparisons. - Rather than writing to a real temporary file, you could marshal to a string and than unmarshal from a StringIO file. - And the big whopper: rather than using a modified version of unmarshal, I suggest writing a recursive code object transformer. It takes a code object and a replace_paths list, and returns a similar code object with the co_filename attribute changed according to the list. The trick is that it should also do this, recursively, to any code object found in the co_consts tuple. (That's the only place where code objects can occur recursively.) While this is probably not much less code than the marshaller you wrote, it has the advantage of not being dependent on the details of the marshal format. Please upload a new patch -- I'm interested in getting this into Python 2.1. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101702&group_id=5470 From noreply@sourceforge.net Tue Oct 24 20:25:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Oct 2000 12:25:58 -0700 Subject: [Patches] [Patch #102075] More DOM documentation Message-ID: <200010241925.MAA09940@sf-web1.i.sourceforge.net> Patch #102075 has been updated. Project: Category: documentation Status: Closed Summary: More DOM documentation Follow-Ups: Date: 2000-Oct-24 12:25 By: fdrake Comment: Checked in with changes as Doc/lib/xmldom.tex. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102075&group_id=5470 From noreply@sourceforge.net Tue Oct 24 20:31:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Oct 2000 12:31:37 -0700 Subject: [Patches] [Patch #101821] xmldomminidom.tex: Documentation for minidom Message-ID: <200010241931.MAA10073@sf-web1.i.sourceforge.net> Patch #101821 has been updated. Project: Category: documentation Status: Rejected Summary: xmldomminidom.tex: Documentation for minidom Follow-Ups: Date: 2000-Oct-24 12:31 By: fdrake Comment: Rejected; we can't include a huge chunk of IDL in the documentation both because it breaks formatting of the typeset version and it just doesn't seem appropriate (the XML-SIG has already ascertained that the IDL is screwed up and largely ignored). Paul Prescod integrated some of the textual content into the Doc/lib/xmldom.tex section recently checked in, so this was not a wasted effort. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101821&group_id=5470 From noreply@sourceforge.net Tue Oct 24 21:03:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Oct 2000 13:03:48 -0700 Subject: [Patches] [Patch #101839] better error messages Message-ID: <200010242003.NAA07461@sf-web3.vaspecialprojects.com> Patch #101839 has been updated. Project: Category: core (C code) Status: Closed Summary: better error messages Follow-Ups: Date: 2000-Oct-08 20:20 By: ping Comment: This patch tries to make the feedback from error messages more consistent and helpful. For example: >>> os.kf Traceback (most recent call last): File "", line 1, in ? AttributeError: 'os' module has no attribute 'kf' >>> int(a=3) Traceback (most recent call last): File "", line 1, in ? TypeError: int() takes no keyword arguments >>> class Foo: pass ... >>> Foo.spam Traceback (most recent call last): File "", line 1, in ? AttributeError: class Foo has no attribute 'spam' >>> Foo().spam Traceback (most recent call last): File "", line 1, in ? AttributeError: Foo instance has no attribute 'spam' >>> Foo()() Traceback (most recent call last): File "", line 1, in ? AttributeError: Foo instance has no __call__ method This isn't really a bug, but it's not a feature either. I wanted to get it in before the Monday freeze. If you have time, have a look; i'll leave it to your judgement whether it's okay to check in. I know it's close to the wire, but it's effectively small: there are no changes in logic, only strings edited here and there. The corresponding changes to the tests that relied on specific wording of error messages are also included. ------------------------------------------------------- Date: 2000-Oct-08 20:26 By: ping Comment: More examples: >>> import os >>> del os.kf Traceback (most recent call last): File "", line 1, in ? AttributeError: 'os' module has no attribute 'kf' >>> pow(3,4,0) Traceback (most recent call last): File "", line 1, in ? ValueError: pow() arg 3 cannot be 0 >>> os.execv('a', 3) Traceback (most recent call last): File "", line 1, in ? TypeError: execv() arg 2 must be a tuple or list >>> os.execv('a', (3,4)) Traceback (most recent call last): File "", line 1, in ? TypeError: execv() arg 2 must contain only strings >>> 0 ** -4 Traceback (most recent call last): File "", line 1, in ? ZeroDivisionError: cannot raise 0 to a negative power >>> int("45", 1) Traceback (most recent call last): File "", line 1, in ? ValueError: int() base must be >= 2 and <= 36 >>> ord(3) Traceback (most recent call last): File "", line 1, in ? TypeError: ord() expected string or Unicode character, int found ------------------------------------------------------- Date: 2000-Oct-08 20:28 By: ping Comment: Forgot to mention that this patch also includes changed names for audio formats in the linuxaudiodev module. ------------------------------------------------------- Date: 2000-Oct-09 05:32 By: gvanrossum Comment: Sorry, but this has to go in after 2.0 final is released. It's touching way too much code to be snuck in at the very last moment. ------------------------------------------------------- Date: 2000-Oct-24 13:03 By: fdrake Comment: Accepted all except the linuxaudiodev changes, which I couldn't test since that module doesn't work for me anyway. ;-( (We're starting to suspect that whether it actually works is highly dependent on the audio device driver itself -- it doesn't work with the Maestro driver on my laptop.) Ping -- please open a new patch with an updated version of the linuxaudiodev patch (a new element has been added to audio_types). Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101839&group_id=5470 From loewis@informatik.hu-berlin.de Tue Oct 24 21:50:25 2000 From: loewis@informatik.hu-berlin.de (Martin von Loewis) Date: Tue, 24 Oct 2000 22:50:25 +0200 (MET DST) Subject: [Patches] [Patch #101821] xmldomminidom.tex: Documentation for minidom Message-ID: <200010242050.WAA04191@pandora.informatik.hu-berlin.de> > Rejected; we can't include a huge chunk of IDL in the documentation > both because it breaks formatting of the typeset version and it just > doesn't seem appropriate (the XML-SIG has already ascertained that > the IDL is screwed up and largely ignored). Hi Fred, I don't think that rationale for rejection is valid: I can fix the formatting of the typeset version if you want (e.g. by not setting it as a minipage). On not being appropriate: The IDL provides documentation that the English text doesn't. For example, the it doesn't tell what the functions return in many cases (e.g. {remove|append}Child). Also, a number of functions that are implemented and ought to be part of the interface are not documented (e.g. getAttributeNode). Using the IDL would provide a better guarantee of consistency. As for the IDL being screwed: I don't know whether this was a XML-SIG statement (or rather one of individuals); it is certainly not true for DOM Level 1 Second Edition or DOM Level 2 (which the patch proposed to include). I can accept that the IDL is not included in the documentation, but I'd like to see the content that it would have provided written in plain English, then. Regards, Martin From noreply@sourceforge.net Tue Oct 24 21:57:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Oct 2000 13:57:28 -0700 Subject: [Patches] [Patch #101843] Remove all uses of "assert" from the test suite Message-ID: <200010242057.NAA11657@sf-web1.i.sourceforge.net> Patch #101843 has been updated. Project: Category: core (C code) Status: Open Summary: Remove all uses of "assert" from the test suite Follow-Ups: Date: 2000-Oct-09 07:25 By: lemburg Comment: This patch removes all uses of the assert statement from the regression test suite. Use of assert in the suite is depreciated due to asserts being removed from the byte code when Python is run in optimized mode. The patch adds a new function to test_support (verify) which handles the asserts in a more customizable way. It does not rely on the assert statement. I have tested this patch lightly (meaning that the suite runs through just fine). Not all execution paths are testable due to the nature of the patch, though. Please review. ------------------------------------------------------- Date: 2000-Oct-09 12:26 By: gvanrossum Comment: Great! But let's do this post-2.0 final release. I'm really getting worried about patches that touch every file in a particular corner of the universe... :-( ------------------------------------------------------- Date: 2000-Oct-24 13:57 By: gvanrossum Comment: Would you mind resubmitting this? Some of the patches fail, probably because there were a lot of changes to the whitespace. The idea is still as valid as it was before. A style nit: please don't include spaces inside parentheses: please write verify(cond, reason) rather than verify( cond, reason ). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101843&group_id=5470 From noreply@sourceforge.net Tue Oct 24 21:57:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Oct 2000 13:57:41 -0700 Subject: [Patches] [Patch #101843] Remove all uses of "assert" from the test suite Message-ID: <200010242057.NAA11663@sf-web1.i.sourceforge.net> Patch #101843 has been updated. Project: Category: core (C code) Status: Open Summary: Remove all uses of "assert" from the test suite Follow-Ups: Date: 2000-Oct-09 07:25 By: lemburg Comment: This patch removes all uses of the assert statement from the regression test suite. Use of assert in the suite is depreciated due to asserts being removed from the byte code when Python is run in optimized mode. The patch adds a new function to test_support (verify) which handles the asserts in a more customizable way. It does not rely on the assert statement. I have tested this patch lightly (meaning that the suite runs through just fine). Not all execution paths are testable due to the nature of the patch, though. Please review. ------------------------------------------------------- Date: 2000-Oct-09 12:26 By: gvanrossum Comment: Great! But let's do this post-2.0 final release. I'm really getting worried about patches that touch every file in a particular corner of the universe... :-( ------------------------------------------------------- Date: 2000-Oct-24 13:57 By: gvanrossum Comment: Would you mind resubmitting this? Some of the patches fail, probably because there were a lot of changes to the whitespace. The idea is still as valid as it was before. A style nit: please don't include spaces inside parentheses: please write verify(cond, reason) rather than verify( cond, reason ). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101843&group_id=5470 From fdrake@acm.org Tue Oct 24 22:04:02 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 24 Oct 2000 17:04:02 -0400 (EDT) Subject: [Patches] Re: [Patch #101821] xmldomminidom.tex: Documentation for minidom In-Reply-To: <200010242050.WAA04191@pandora.informatik.hu-berlin.de> References: <200010242050.WAA04191@pandora.informatik.hu-berlin.de> Message-ID: <14837.63810.179873.777372@cj42289-a.reston1.va.home.com> Martin von Loewis writes: > I don't think that rationale for rejection is valid: I can fix the > formatting of the typeset version if you want (e.g. by not setting it > as a minipage). Not using the verbatim environment makes further transformations of the docs painful; the last I checked LaTeX2HTML had real problems with alltt environments. I'm not sure what you're thinking of specifically, so can't offer much advice on the right markup, but I'd like to keep it simple in any case. > On not being appropriate: The IDL provides documentation that the > English text doesn't. For example, the it doesn't tell what the > functions return in many cases (e.g. {remove|append}Child). Also, a > number of functions that are implemented and ought to be part of the > interface are not documented (e.g. getAttributeNode). Using the IDL > would provide a better guarantee of consistency. I think we only get consistency here if we link to the IDL on www.w3.org; if we include it ourselves, we're just as well off if we document the methods directly. This would be my preference. > As for the IDL being screwed: I don't know whether this was a XML-SIG > statement (or rather one of individuals); it is certainly not true for > DOM Level 1 Second Edition or DOM Level 2 (which the patch proposed to > include). I thought we determined that there were IDL errors in one version or another; perhaps that's been corrected. Perhaps it was the case in DOM Level 1 first ed.; I don't recall when the discussions took place, and really don't want to scour the archives right now. I also seem to recall that the Python DOM API is not a direct mapping using the IDL->Python mapping as accepted by the OMG. That seems a good reason not to include the IDL, as the association between IDL and CORBA is tight, and misleading in this case. > I can accept that the IDL is not included in the documentation, but > I'd like to see the content that it would have provided written in > plain English, then. Agreed; my intent was not to exclude the information content, regardless of the presentation. If we want to include the IDL, we should do so via a hyperlink, which is problematic for the typeset versions. Breaking it up into smaller chunks would be nightmarish as well. At any rate, I do plan to attack this section again this week, so I'll take all this into consideration. I agree that we need more information here, and should not rely excessively on the reader interpolating the W3C documents and what we provide to figure it out. -Fred -- Fred L. Drake, Jr. PythonLabs Team Member From noreply@sourceforge.net Wed Oct 25 04:34:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Oct 2000 20:34:21 -0700 Subject: [Patches] [Patch #102106] sys._getframe() for getting the current stack frame Message-ID: <200010250334.UAA04550@sf-web2.i.sourceforge.net> Patch #102106 has been updated. Project: Category: None Status: Open Summary: sys._getframe() for getting the current stack frame ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102106&group_id=5470 From noreply@sourceforge.net Wed Oct 25 04:43:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Oct 2000 20:43:36 -0700 Subject: [Patches] [Patch #102106] sys._getframe() for getting the current stack frame Message-ID: <200010250343.UAA14996@sf-web3.vaspecialprojects.com> Patch #102106 has been updated. Project: Category: core (C code) Status: Open Summary: sys._getframe() for getting the current stack frame Follow-Ups: Date: 2000-Oct-24 20:43 By: bwarsaw Comment: This patch adds a function to the sys module which will return a frame object. By default, it returns the frame object of the current stack frame, but an optional integer argument can be supplied to retrieve any frame higher up the stack. If the integer is greater than the depth of the stack, a ValueError is raised. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102106&group_id=5470 From noreply@sourceforge.net Wed Oct 25 05:43:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Oct 2000 21:43:28 -0700 Subject: [Patches] [Patch #102106] sys._getframe() for getting the current stack frame Message-ID: <200010250443.VAA05630@sf-web2.i.sourceforge.net> Patch #102106 has been updated. Project: Category: core (C code) Status: Open Summary: sys._getframe() for getting the current stack frame Follow-Ups: Date: 2000-Oct-24 20:43 By: bwarsaw Comment: This patch adds a function to the sys module which will return a frame object. By default, it returns the frame object of the current stack frame, but an optional integer argument can be supplied to retrieve any frame higher up the stack. If the integer is greater than the depth of the stack, a ValueError is raised. ------------------------------------------------------- Date: 2000-Oct-24 21:43 By: fdrake Comment: My only comment on the docs (both docstring and LaTeX) is that it should say "ValueError is raised" rather than "a ValueError is raised" (drop the "a"). Otherwise looks good; I've not run it through the formatting. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102106&group_id=5470 From noreply@sourceforge.net Wed Oct 25 05:51:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Oct 2000 21:51:13 -0700 Subject: [Patches] [Patch #102106] sys._getframe() for getting the current stack frame Message-ID: <200010250451.VAA05759@sf-web2.i.sourceforge.net> Patch #102106 has been updated. Project: Category: core (C code) Status: Open Summary: sys._getframe() for getting the current stack frame Follow-Ups: Date: 2000-Oct-24 20:43 By: bwarsaw Comment: This patch adds a function to the sys module which will return a frame object. By default, it returns the frame object of the current stack frame, but an optional integer argument can be supplied to retrieve any frame higher up the stack. If the integer is greater than the depth of the stack, a ValueError is raised. ------------------------------------------------------- Date: 2000-Oct-24 21:43 By: fdrake Comment: My only comment on the docs (both docstring and LaTeX) is that it should say "ValueError is raised" rather than "a ValueError is raised" (drop the "a"). Otherwise looks good; I've not run it through the formatting. ------------------------------------------------------- Date: 2000-Oct-24 21:51 By: bwarsaw Comment: Good point. Patch updated. Thanks. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102106&group_id=5470 From noreply@sourceforge.net Wed Oct 25 05:54:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Oct 2000 21:54:49 -0700 Subject: [Patches] [Patch #102106] sys._getframe() for getting the current stack frame Message-ID: <200010250454.VAA05849@sf-web2.i.sourceforge.net> Patch #102106 has been updated. Project: Category: core (C code) Status: Open Summary: sys._getframe() for getting the current stack frame Follow-Ups: Date: 2000-Oct-24 20:43 By: bwarsaw Comment: This patch adds a function to the sys module which will return a frame object. By default, it returns the frame object of the current stack frame, but an optional integer argument can be supplied to retrieve any frame higher up the stack. If the integer is greater than the depth of the stack, a ValueError is raised. ------------------------------------------------------- Date: 2000-Oct-24 21:43 By: fdrake Comment: My only comment on the docs (both docstring and LaTeX) is that it should say "ValueError is raised" rather than "a ValueError is raised" (drop the "a"). Otherwise looks good; I've not run it through the formatting. ------------------------------------------------------- Date: 2000-Oct-24 21:51 By: bwarsaw Comment: Good point. Patch updated. Thanks. ------------------------------------------------------- Date: 2000-Oct-24 21:54 By: bwarsaw Comment: Oops, fixed one small typo. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102106&group_id=5470 From noreply@sourceforge.net Wed Oct 25 09:36:14 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Oct 2000 01:36:14 -0700 Subject: [Patches] [Patch #101702] Modify co_filename in frozen programs Message-ID: <200010250836.BAA19380@sf-web3.vaspecialprojects.com> Patch #101702 has been updated. Project: Category: demos and tools Status: Open Summary: Modify co_filename in frozen programs Follow-Ups: Date: 2000-Sep-29 04:39 By: lhudson Comment: A new feature for freeze. This patch was developed primarily to reduce the size of the frozen binary. It is particularly useful when freezing for 'small' platforms, such as Palm OS, where you really want to save that last miserable byte. A limitation of this patch is that it does not provide any feedback about the replacements being made. As the path matching is case-sensitive this may lead to unexpected behaviour for DOS and Windows people, eg > freeze.py -r C:\Python\Lib\=py\ goats.py should probably be: > freeze.py -r c:\python\lib\=py\ goats.py ------------------------------------------------------- Date: 2000-Sep-29 07:28 By: jhylton Comment: This sounds like a reasonable enough feature, but we are in feature freeze for Python 2.0. ------------------------------------------------------- Date: 2000-Oct-23 12:33 By: gvanrossum Comment: I like the idea, but I have a few suggestions. - To avoid the case sensitivity issue you mention, you could use os.path.normpath() before the string comparisons. - Rather than writing to a real temporary file, you could marshal to a string and than unmarshal from a StringIO file. - And the big whopper: rather than using a modified version of unmarshal, I suggest writing a recursive code object transformer. It takes a code object and a replace_paths list, and returns a similar code object with the co_filename attribute changed according to the list. The trick is that it should also do this, recursively, to any code object found in the co_consts tuple. (That's the only place where code objects can occur recursively.) While this is probably not much less code than the marshaller you wrote, it has the advantage of not being dependent on the details of the marshal format. Please upload a new patch -- I'm interested in getting this into Python 2.1. ------------------------------------------------------- Date: 2000-Oct-25 01:36 By: lhudson Comment: A recursive code object transformer has been implemented as a member of the ModuleFinder. Case sensitivity issue: normpath strips trailing '/' or '\\' which reduces the flexibility of the path replacement. It also does not seem to solve the case-sensitivity problem: D:\>python Python 2.0 (#8, Oct 17 2000, 15:27:24) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import os >>> os.path.normpath("c:\\python\\lib\\") 'c:\\python\\lib' >>> os.path.normpath("c:\\python\\Lib\\") 'c:\\python\\Lib' >>> ModuleFinder's debugging system is used to report the status of each unique path encountered. Temporary file: marshal.dump() and marshal.load() only work with file objects, not file-like objects. Now that new code objects are being created there is no longer any reason to re-marshal so this problem disappears. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101702&group_id=5470 From noreply@sourceforge.net Wed Oct 25 12:19:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Oct 2000 04:19:56 -0700 Subject: [Patches] [Patch #101702] Modify co_filename in frozen programs Message-ID: <200010251119.EAA22051@sf-web3.vaspecialprojects.com> Patch #101702 has been updated. Project: Category: demos and tools Status: Open Summary: Modify co_filename in frozen programs Follow-Ups: Date: 2000-Sep-29 04:39 By: lhudson Comment: A new feature for freeze. This patch was developed primarily to reduce the size of the frozen binary. It is particularly useful when freezing for 'small' platforms, such as Palm OS, where you really want to save that last miserable byte. A limitation of this patch is that it does not provide any feedback about the replacements being made. As the path matching is case-sensitive this may lead to unexpected behaviour for DOS and Windows people, eg > freeze.py -r C:\Python\Lib\=py\ goats.py should probably be: > freeze.py -r c:\python\lib\=py\ goats.py ------------------------------------------------------- Date: 2000-Sep-29 07:28 By: jhylton Comment: This sounds like a reasonable enough feature, but we are in feature freeze for Python 2.0. ------------------------------------------------------- Date: 2000-Oct-23 12:33 By: gvanrossum Comment: I like the idea, but I have a few suggestions. - To avoid the case sensitivity issue you mention, you could use os.path.normpath() before the string comparisons. - Rather than writing to a real temporary file, you could marshal to a string and than unmarshal from a StringIO file. - And the big whopper: rather than using a modified version of unmarshal, I suggest writing a recursive code object transformer. It takes a code object and a replace_paths list, and returns a similar code object with the co_filename attribute changed according to the list. The trick is that it should also do this, recursively, to any code object found in the co_consts tuple. (That's the only place where code objects can occur recursively.) While this is probably not much less code than the marshaller you wrote, it has the advantage of not being dependent on the details of the marshal format. Please upload a new patch -- I'm interested in getting this into Python 2.1. ------------------------------------------------------- Date: 2000-Oct-25 01:36 By: lhudson Comment: A recursive code object transformer has been implemented as a member of the ModuleFinder. Case sensitivity issue: normpath strips trailing '/' or '\\' which reduces the flexibility of the path replacement. It also does not seem to solve the case-sensitivity problem: D:\>python Python 2.0 (#8, Oct 17 2000, 15:27:24) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import os >>> os.path.normpath("c:\\python\\lib\\") 'c:\\python\\lib' >>> os.path.normpath("c:\\python\\Lib\\") 'c:\\python\\Lib' >>> ModuleFinder's debugging system is used to report the status of each unique path encountered. Temporary file: marshal.dump() and marshal.load() only work with file objects, not file-like objects. Now that new code objects are being created there is no longer any reason to re-marshal so this problem disappears. ------------------------------------------------------- Date: 2000-Oct-25 04:19 By: gvanrossum Comment: Thanks for the new patch! I'll assign this to Jeremy for further review and to carry it to completion. (Jeremy, if you're swamped, please find someone else to do it.) Re normpath: my mistake -- I meant normcase. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101702&group_id=5470 From noreply@sourceforge.net Wed Oct 25 21:01:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Oct 2000 13:01:59 -0700 Subject: [Patches] [Patch #101019] Opcode reordering Message-ID: <200010252001.NAA03280@sf-web1.i.sourceforge.net> Patch #101019 has been updated. Project: python Category: core (C code) Status: Rejected Summary: Opcode reordering Follow-Ups: Date: 2000-Jul-30 01:34 By: marangoz Comment: Mainly for peace of mind - as discussed on python-dev, aims at reducing cache effects. The Top5 opcodes have been moved to the beginning of the main loop, ordered by decreasing frequency according to DXP and MAL's statistics. LOAD_FAST & LOAD_CONST have been slightly tweaked so that the code sequence is 'unique' amongst the other opcodes. Otherwise, the optimizer is likely to generate a jump to another common block later in the loop which obviates the whole point of moving these opcodes to the top. - The condition in LOAD_FAST is inversed - LOAD_CONST has been changed from 'break' to 'continue'. Indeed, if x == NULL, we would have dumped core at the Py_INCREF(x) preceding the break... Some testing on Lunix, Solaris and AIX shows no slowdowns . There seems to be some speedup, but in some cases it is barely noticeable. I dropped the idea of folding opcodes. The bahavior is unpredictable. If someone wants to spend her entire life between balancing caching and pipelining in ceval.c, no problem . I'm out of this game. As usual, please test (notably on Windows) ------------------------------------------------------- Date: 2000-Jul-31 06:43 By: gvanrossum Comment: Status set to Postponed, just to indicate that this is still experimental and not slated for inclusion into 2.0. Thanks for submitting this though -- it's good that it's recorded somewhere. ------------------------------------------------------- Date: 2000-Oct-25 13:01 By: gvanrossum Comment: I played with this a bit, but the effect seems negligeable. So why do it? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101019&group_id=5470 From noreply@sourceforge.net Wed Oct 25 21:41:14 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Oct 2000 13:41:14 -0700 Subject: [Patches] [Patch #102114] Make *shared* modules work on OpenBSD (bug 117245) Message-ID: <200010252041.NAA01198@sf-web2.i.sourceforge.net> Patch #102114 has been updated. Project: python Category: None Status: Open Summary: Make *shared* modules work on OpenBSD (bug 117245) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102114&group_id=5470 From noreply@sourceforge.net Wed Oct 25 21:43:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Oct 2000 13:43:29 -0700 Subject: [Patches] [Patch #102114] Make *shared* modules work on OpenBSD (bug 117245) Message-ID: <200010252043.NAA01266@sf-web2.i.sourceforge.net> Patch #102114 has been updated. Project: python Category: None Status: Open Summary: Make *shared* modules work on OpenBSD (bug 117245) Follow-Ups: Date: 2000-Oct-25 13:43 By: gvanrossum Comment: Thomas, can you test this on OpenBSD? If not, assign it back to me. I happened to remember that someone had told me that on OpenBSD you need a leading underscore... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102114&group_id=5470 From noreply@sourceforge.net Wed Oct 25 21:50:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Oct 2000 13:50:41 -0700 Subject: [Patches] [Patch #101527] ustr Message-ID: <200010252050.NAA01407@sf-web2.i.sourceforge.net> Patch #101527 has been updated. Project: python Category: None Status: Rejected Summary: ustr Follow-Ups: Date: 2000-Sep-15 03:17 By: htrd Comment: In July on i18n-sig, we discussed the need for a builtin function like "str" but which could return any string-like object. Guido endorsed the idea http://www.python.org/pipermail/i18n-sig/2000-July/000338.html but no patch has been submitted. I know its too late to add this as a builtin for 2.0. Is it too late to add it to the string module? ------------------------------------------------------- Date: 2000-Sep-15 06:16 By: gvanrossum Comment: I think we should not do this now. A feature freeze is a feature freeze. :-) Let's see if the need really exists once 2.0 is released and then we can add it to 2.1. I'm sure there are lots of other things that we find would be useful to add, once there's some real experience using the new Unicode stuff. ------------------------------------------------------- Date: 2000-Oct-25 13:50 By: gvanrossum Comment: The patch isn't really a patch -- it's just pseudo code for an implementation. I see several problems with this, not the least of which is that the C API PyObject_Str() forces str() to return an 8-bit string. You could propose to add a PyObject_UStr() that doesn't have this requirement but I think this requires more discussion than this space provides -- there are other drawbacks. I've added an entry to PEP-42 instead; I'm rejecting this patch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101527&group_id=5470 From noreply@sourceforge.net Wed Oct 25 21:54:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Oct 2000 13:54:59 -0700 Subject: [Patches] [Patch #101647] adds SSL server socket support to socketmodule.c Message-ID: <200010252054.NAA01497@sf-web2.i.sourceforge.net> Patch #101647 has been updated. Project: python Category: Modules Status: Open Summary: adds SSL server socket support to socketmodule.c Follow-Ups: Date: 2000-Sep-25 09:41 By: jhylton Comment: too late for 2.0 ------------------------------------------------------- Date: 2000-Sep-27 03:51 By: naris Comment: too late ? this patch solves world hunger and brings world peace! such a valuable patch, but i guess deadlines are deadlines :-( ------------------------------------------------------- Date: 2000-Oct-25 13:54 By: gvanrossum Comment: Drew, could you provide an example of how this is used? If I can't test it I can't add it. It doesn't have to be a test module (although a test module for all the SSL support is sorely needed) but I would like to see a little motivation for why this is useful. Also note that the SSL support in the socket module is controversial; there are some who believe that a different approach is needed, e.g. based on M2crypto. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101647&group_id=5470 From noreply@sourceforge.net Wed Oct 25 21:56:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Oct 2000 13:56:59 -0700 Subject: [Patches] [Patch #101022] Removal of SET_LINENO (experimental) Message-ID: <200010252056.NAA01534@sf-web2.i.sourceforge.net> Patch #101022 has been updated. Project: python Category: core (C code) Status: Open Summary: Removal of SET_LINENO (experimental) Follow-Ups: Date: 2000-Jul-30 16:12 By: marangoz Comment: For testing, as discussed on python-dev. For a gentle summary, see: http://www.python.org/pipermail/python-dev/2000-July/014364.html ------------------------------------------------------- Date: 2000-Jul-30 18:16 By: marangoz Comment: A nit: inline the argfetch in CALL_TRACE and goto the switch, instead of jumping to get_oparg which splits the sequence [fetch opcode, fetch oparg] -- this can slow things down. ------------------------------------------------------- Date: 2000-Jul-31 06:40 By: gvanrossum Comment: Status set to postponed to indicate that this is still experimental. ------------------------------------------------------- Date: 2000-Jul-31 07:57 By: marangoz Comment: Another rewrite, making this whole strategy b/w compatible according to the 1st incompatibility point a) described in: http://www.python.org/pipermail/python-dev/2000-July/014364.html Changes: 1. f.f_lineno is computed and updated on f_lineno attribute requests for f, given f.f_lasti. Correctness is ensured because f.f_lasti is updated on *all* attribute accesses (in LOAD_ATTR in the main loop). 2. The standard setup does not generate SET_LINENO, but uses co_lnotab for computing the source line number (e.g. tracebacks) This is equivalent to the actual "python -O". 3. With "python -d", we fall back to the current version of the interpreter (with SET_LINENO) thus making it easy to test whether this patch fully replaces SET_LINENO's behavior. (modulo f->f_lineno accesses from legacy C code, but this is insane). IMO, this version already worths the pain to be truly tested and improved. One improvement is to define a nicer public C API for breakpoints: - PyCode_SetBreakPointAtLine(line) - PyCode_SetBreakPointAtAddr(addr) or similar, which would install a CALL_TRACE opcode in the appropriate location of the copy of co_code. Another idea is to avoid duplicating the entire co_code just for storing the CALL_TRACE opcodes. We can store them in the original and keep a table of breakpoints. Setting the breakpoints would occur whenever the sys.settrace hook is set. ------------------------------------------------------- Date: 2000-Jul-31 10:50 By: marangoz Comment: A last tiny fix of the SET_LINENO opcode for better b/w compatibility. Stopping here and entering standby mode for reactions & feedback. PS: the last idea about not duplicating co_code and tweaking the original with CALL_TRACE is a bad one. I remember Guido being against it because co_code could be used elsewhere (copied, written to disk, whatever) and he's right! Better operate on an internal copy created in ceval. ------------------------------------------------------- Date: 2000-Aug-03 12:22 By: marangoz Comment: Fix missing DECREF on error condition in start_tracing() + some renaming. ------------------------------------------------------- Date: 2000-Oct-25 13:56 By: gvanrossum Comment: Vladimir, are you there? The patch doesn't apply cleanly to the current CVS tree any more... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101022&group_id=5470 From noreply@sourceforge.net Wed Oct 25 23:08:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Oct 2000 15:08:55 -0700 Subject: [Patches] [Patch #102114] Make *shared* modules work on OpenBSD (bug 117245) Message-ID: <200010252208.PAA02152@sf-web3.vaspecialprojects.com> Patch #102114 has been updated. Project: python Category: None Status: Closed Summary: Make *shared* modules work on OpenBSD (bug 117245) Follow-Ups: Date: 2000-Oct-25 13:43 By: gvanrossum Comment: Thomas, can you test this on OpenBSD? If not, assign it back to me. I happened to remember that someone had told me that on OpenBSD you need a leading underscore... ------------------------------------------------------- Date: 2000-Oct-25 15:08 By: gvanrossum Comment: Applied (with #endif). Never mind, Thomas -- it works. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102114&group_id=5470 From noreply@sourceforge.net Thu Oct 26 01:42:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Oct 2000 17:42:41 -0700 Subject: [Patches] [Patch #101022] Removal of SET_LINENO (experimental) Message-ID: <200010260042.RAA04865@sf-web3.vaspecialprojects.com> Patch #101022 has been updated. Project: python Category: core (C code) Status: Open Summary: Removal of SET_LINENO (experimental) Follow-Ups: Date: 2000-Jul-30 16:12 By: marangoz Comment: For testing, as discussed on python-dev. For a gentle summary, see: http://www.python.org/pipermail/python-dev/2000-July/014364.html ------------------------------------------------------- Date: 2000-Jul-30 18:16 By: marangoz Comment: A nit: inline the argfetch in CALL_TRACE and goto the switch, instead of jumping to get_oparg which splits the sequence [fetch opcode, fetch oparg] -- this can slow things down. ------------------------------------------------------- Date: 2000-Jul-31 06:40 By: gvanrossum Comment: Status set to postponed to indicate that this is still experimental. ------------------------------------------------------- Date: 2000-Jul-31 07:57 By: marangoz Comment: Another rewrite, making this whole strategy b/w compatible according to the 1st incompatibility point a) described in: http://www.python.org/pipermail/python-dev/2000-July/014364.html Changes: 1. f.f_lineno is computed and updated on f_lineno attribute requests for f, given f.f_lasti. Correctness is ensured because f.f_lasti is updated on *all* attribute accesses (in LOAD_ATTR in the main loop). 2. The standard setup does not generate SET_LINENO, but uses co_lnotab for computing the source line number (e.g. tracebacks) This is equivalent to the actual "python -O". 3. With "python -d", we fall back to the current version of the interpreter (with SET_LINENO) thus making it easy to test whether this patch fully replaces SET_LINENO's behavior. (modulo f->f_lineno accesses from legacy C code, but this is insane). IMO, this version already worths the pain to be truly tested and improved. One improvement is to define a nicer public C API for breakpoints: - PyCode_SetBreakPointAtLine(line) - PyCode_SetBreakPointAtAddr(addr) or similar, which would install a CALL_TRACE opcode in the appropriate location of the copy of co_code. Another idea is to avoid duplicating the entire co_code just for storing the CALL_TRACE opcodes. We can store them in the original and keep a table of breakpoints. Setting the breakpoints would occur whenever the sys.settrace hook is set. ------------------------------------------------------- Date: 2000-Jul-31 10:50 By: marangoz Comment: A last tiny fix of the SET_LINENO opcode for better b/w compatibility. Stopping here and entering standby mode for reactions & feedback. PS: the last idea about not duplicating co_code and tweaking the original with CALL_TRACE is a bad one. I remember Guido being against it because co_code could be used elsewhere (copied, written to disk, whatever) and he's right! Better operate on an internal copy created in ceval. ------------------------------------------------------- Date: 2000-Aug-03 12:22 By: marangoz Comment: Fix missing DECREF on error condition in start_tracing() + some renaming. ------------------------------------------------------- Date: 2000-Oct-25 13:56 By: gvanrossum Comment: Vladimir, are you there? The patch doesn't apply cleanly to the current CVS tree any more... ------------------------------------------------------- Date: 2000-Oct-25 17:42 By: marangoz Comment: noreply@sourceforge.net wrote: > > Date: 2000-Oct-25 13:56 > By: gvanrossum > > Comment: > Vladimir, are you there? So-so :) I'm a moving target, checking my mail occasionally these days. Luckily, today is one of these days. > > The patch doesn't apply cleanly to the current CVS tree any more... Ah, this one's easy. Here's an update relative to 2.0 final, not CVS. I got some r/w access error trying to update my CVS copy from SF that I have no time to investigate right now... The Web interface still works though :) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101022&group_id=5470 From noreply@sourceforge.net Thu Oct 26 01:42:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Oct 2000 17:42:41 -0700 Subject: [Patches] [Patch #101022] Removal of SET_LINENO (experimental) Message-ID: <200010260042.RAA04868@sf-web3.vaspecialprojects.com> Patch #101022 has been updated. Project: python Category: core (C code) Status: Open Summary: Removal of SET_LINENO (experimental) Follow-Ups: Date: 2000-Jul-30 16:12 By: marangoz Comment: For testing, as discussed on python-dev. For a gentle summary, see: http://www.python.org/pipermail/python-dev/2000-July/014364.html ------------------------------------------------------- Date: 2000-Jul-30 18:16 By: marangoz Comment: A nit: inline the argfetch in CALL_TRACE and goto the switch, instead of jumping to get_oparg which splits the sequence [fetch opcode, fetch oparg] -- this can slow things down. ------------------------------------------------------- Date: 2000-Jul-31 06:40 By: gvanrossum Comment: Status set to postponed to indicate that this is still experimental. ------------------------------------------------------- Date: 2000-Jul-31 07:57 By: marangoz Comment: Another rewrite, making this whole strategy b/w compatible according to the 1st incompatibility point a) described in: http://www.python.org/pipermail/python-dev/2000-July/014364.html Changes: 1. f.f_lineno is computed and updated on f_lineno attribute requests for f, given f.f_lasti. Correctness is ensured because f.f_lasti is updated on *all* attribute accesses (in LOAD_ATTR in the main loop). 2. The standard setup does not generate SET_LINENO, but uses co_lnotab for computing the source line number (e.g. tracebacks) This is equivalent to the actual "python -O". 3. With "python -d", we fall back to the current version of the interpreter (with SET_LINENO) thus making it easy to test whether this patch fully replaces SET_LINENO's behavior. (modulo f->f_lineno accesses from legacy C code, but this is insane). IMO, this version already worths the pain to be truly tested and improved. One improvement is to define a nicer public C API for breakpoints: - PyCode_SetBreakPointAtLine(line) - PyCode_SetBreakPointAtAddr(addr) or similar, which would install a CALL_TRACE opcode in the appropriate location of the copy of co_code. Another idea is to avoid duplicating the entire co_code just for storing the CALL_TRACE opcodes. We can store them in the original and keep a table of breakpoints. Setting the breakpoints would occur whenever the sys.settrace hook is set. ------------------------------------------------------- Date: 2000-Jul-31 10:50 By: marangoz Comment: A last tiny fix of the SET_LINENO opcode for better b/w compatibility. Stopping here and entering standby mode for reactions & feedback. PS: the last idea about not duplicating co_code and tweaking the original with CALL_TRACE is a bad one. I remember Guido being against it because co_code could be used elsewhere (copied, written to disk, whatever) and he's right! Better operate on an internal copy created in ceval. ------------------------------------------------------- Date: 2000-Aug-03 12:22 By: marangoz Comment: Fix missing DECREF on error condition in start_tracing() + some renaming. ------------------------------------------------------- Date: 2000-Oct-25 13:56 By: gvanrossum Comment: Vladimir, are you there? The patch doesn't apply cleanly to the current CVS tree any more... ------------------------------------------------------- Date: 2000-Oct-25 17:42 By: marangoz Comment: noreply@sourceforge.net wrote: > > Date: 2000-Oct-25 13:56 > By: gvanrossum > > Comment: > Vladimir, are you there? So-so :) I'm a moving target, checking my mail occasionally these days. Luckily, today is one of these days. > > The patch doesn't apply cleanly to the current CVS tree any more... Ah, this one's easy. Here's an update relative to 2.0 final, not CVS. I got some r/w access error trying to update my CVS copy from SF that I have no time to investigate right now... The Web interface still works though :) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101022&group_id=5470 From noreply@sourceforge.net Thu Oct 26 12:21:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Oct 2000 04:21:06 -0700 Subject: [Patches] [Patch #101527] ustr Message-ID: <200010261121.EAA18068@sf-web3.vaspecialprojects.com> Patch #101527 has been updated. Project: python Category: None Status: Rejected Summary: ustr Follow-Ups: Date: 2000-Sep-15 03:17 By: htrd Comment: In July on i18n-sig, we discussed the need for a builtin function like "str" but which could return any string-like object. Guido endorsed the idea http://www.python.org/pipermail/i18n-sig/2000-July/000338.html but no patch has been submitted. I know its too late to add this as a builtin for 2.0. Is it too late to add it to the string module? ------------------------------------------------------- Date: 2000-Sep-15 06:16 By: gvanrossum Comment: I think we should not do this now. A feature freeze is a feature freeze. :-) Let's see if the need really exists once 2.0 is released and then we can add it to 2.1. I'm sure there are lots of other things that we find would be useful to add, once there's some real experience using the new Unicode stuff. ------------------------------------------------------- Date: 2000-Oct-25 13:50 By: gvanrossum Comment: The patch isn't really a patch -- it's just pseudo code for an implementation. I see several problems with this, not the least of which is that the C API PyObject_Str() forces str() to return an 8-bit string. You could propose to add a PyObject_UStr() that doesn't have this requirement but I think this requires more discussion than this space provides -- there are other drawbacks. I've added an entry to PEP-42 instead; I'm rejecting this patch. ------------------------------------------------------- Date: 2000-Oct-26 04:20 By: lemburg Comment: FYI, there's a true patch which implements unistr() and provides a C API PyObject_Unicode(): patch #101664. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101527&group_id=5470 From noreply@sourceforge.net Thu Oct 26 12:20:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Oct 2000 04:20:57 -0700 Subject: [Patches] [Patch #101527] ustr Message-ID: <200010261120.EAA18063@sf-web3.vaspecialprojects.com> Patch #101527 has been updated. Project: python Category: None Status: Rejected Summary: ustr Follow-Ups: Date: 2000-Sep-15 03:17 By: htrd Comment: In July on i18n-sig, we discussed the need for a builtin function like "str" but which could return any string-like object. Guido endorsed the idea http://www.python.org/pipermail/i18n-sig/2000-July/000338.html but no patch has been submitted. I know its too late to add this as a builtin for 2.0. Is it too late to add it to the string module? ------------------------------------------------------- Date: 2000-Sep-15 06:16 By: gvanrossum Comment: I think we should not do this now. A feature freeze is a feature freeze. :-) Let's see if the need really exists once 2.0 is released and then we can add it to 2.1. I'm sure there are lots of other things that we find would be useful to add, once there's some real experience using the new Unicode stuff. ------------------------------------------------------- Date: 2000-Oct-25 13:50 By: gvanrossum Comment: The patch isn't really a patch -- it's just pseudo code for an implementation. I see several problems with this, not the least of which is that the C API PyObject_Str() forces str() to return an 8-bit string. You could propose to add a PyObject_UStr() that doesn't have this requirement but I think this requires more discussion than this space provides -- there are other drawbacks. I've added an entry to PEP-42 instead; I'm rejecting this patch. ------------------------------------------------------- Date: 2000-Oct-26 04:20 By: lemburg Comment: FYI, there's a true patch which implements unistr() and provides a C API PyObject_Unicode(): patch #101664. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101527&group_id=5470 From noreply@sourceforge.net Thu Oct 26 15:15:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Oct 2000 07:15:45 -0700 Subject: [Patches] [Patch #102106] sys._getframe() for getting the current stack frame Message-ID: <200010261415.HAA20083@sf-web1.i.sourceforge.net> Patch #102106 has been updated. Project: python Category: core (C code) Status: Open Summary: sys._getframe() for getting the current stack frame Follow-Ups: Date: 2000-Oct-24 20:43 By: bwarsaw Comment: This patch adds a function to the sys module which will return a frame object. By default, it returns the frame object of the current stack frame, but an optional integer argument can be supplied to retrieve any frame higher up the stack. If the integer is greater than the depth of the stack, a ValueError is raised. ------------------------------------------------------- Date: 2000-Oct-24 21:43 By: fdrake Comment: My only comment on the docs (both docstring and LaTeX) is that it should say "ValueError is raised" rather than "a ValueError is raised" (drop the "a"). Otherwise looks good; I've not run it through the formatting. ------------------------------------------------------- Date: 2000-Oct-24 21:51 By: bwarsaw Comment: Good point. Patch updated. Thanks. ------------------------------------------------------- Date: 2000-Oct-24 21:54 By: bwarsaw Comment: Oops, fixed one small typo. ------------------------------------------------------- Date: 2000-Oct-26 07:15 By: gvanrossum Comment: The docstring and docs should say that the default depth is zero. They should also mention that this is for internal use only. Can you implement this in Jython too? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102106&group_id=5470 From noreply@sourceforge.net Thu Oct 26 21:47:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Oct 2000 13:47:58 -0700 Subject: [Patches] [Patch #101250] Use '*args' instead of providing defaults in User*.py Message-ID: <200010262047.NAA28569@sf-web1.i.sourceforge.net> Patch #101250 has been updated. Project: python Category: library Status: Rejected Summary: Use '*args' instead of providing defaults in User*.py Follow-Ups: Date: 2000-Aug-21 09:30 By: twouters Comment: Use the '*args' construct rather than providing function defaults that are passed on to the underlying datatype, in the UserList, UserDict and UserString modules. Note: UserString.encode() might like a **kwargs argument as well, I don't know how it's used. ------------------------------------------------------- Date: 2000-Aug-21 17:27 By: tim_one Comment: Postponed, unless you can justify why this should be considered a bugfix instead of a new feature. I confess I don't see the point even as a feature: the list etc interfaces are well-defined, and aren't *meant* to support arbitrary collections of signatures. Passing on arbitrary *args *will* have the effect of making tracebacks more confusing when things finally get down to the level where the concrete implementation finally gets a chance to complain about a goofy arglist. ------------------------------------------------------- Date: 2000-Oct-26 13:47 By: gvanrossum Comment: Rejected, for the reason Tim states: it's *better* to be explicit about the arguments. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101250&group_id=5470 From noreply@sourceforge.net Thu Oct 26 21:51:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Oct 2000 13:51:03 -0700 Subject: [Patches] [Patch #100803] puremodule: ANSI-fication (UNTESTED!) Message-ID: <200010262051.NAA28631@sf-web1.i.sourceforge.net> Patch #100803 has been updated. Project: python Category: None Status: Accepted Summary: puremodule: ANSI-fication (UNTESTED!) Follow-Ups: Date: 2000-Jul-10 10:16 By: nowonder Comment: cannot test this, maybe Barry can ------------------------------------------------------- Date: 2000-Jul-31 01:46 By: nowonder Comment: should I just check it in? Did you get around to review it? ------------------------------------------------------- Date: 2000-Jul-31 09:30 By: bwarsaw Comment: There's one typo in nowonder's patch. Here's a fixed version of the patch (unified). This compiles but doesn't link. I can't tell if this is caused by a problem with the purify stub libraries. Meta note: because this is a commercial product which it seems no one has access to anymore, should we continue to support it in the standard distribution? ------------------------------------------------------- Date: 2000-Jul-31 10:30 By: gvanrossum Comment: Since no-one can test this, let's be conservative and not check it in. There's no absolute requirement to move *everything* to ANSI. Since we know the old version worked, we should leave it alone. I vote to keep this in the distribution -- maybe someone else can use it. If someone else can confirm that it in fact works (or make it work) I'd be happy to accept the patch at that point. ------------------------------------------------------- Date: 2000-Oct-26 13:51 By: gvanrossum Comment: Barry, why don't you check this in. In the next half year, we'll go through enough alpha and beta tests for 2.1 to make sure that someone will test the new module; and if nobody does, it's likely that nobody ever uses it, so then it doesn't matter. :-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100803&group_id=5470 From noreply@sourceforge.net Thu Oct 26 21:58:14 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Oct 2000 13:58:14 -0700 Subject: [Patches] [Patch #100899] a smaller unicode name database Message-ID: <200010262058.NAA29848@sf-web2.i.sourceforge.net> Patch #100899 has been updated. Project: python Category: None Status: Closed Summary: a smaller unicode name database Follow-Ups: Date: 2000-Jul-15 15:43 By: effbot Comment: duh. it's too large for sourceforge. if you want to play with it, get it from: http://w1.132.telia.com/~u13208596/uninames-patch.txt ------------------------------------------------------- Date: 2000-Aug-03 11:59 By: lemburg Comment: How is the work on this patch coming along ? Will it be ready for 2.0 ? ------------------------------------------------------- Date: 2000-Aug-15 10:42 By: tim_one Comment: /F or MAL, what's going on with this? MAL, did you look at the patch? /F, do you feel it's done? ------------------------------------------------------- Date: 2000-Aug-23 11:39 By: tim_one Comment: Assigned back to /F because he agrees the ball bounced back into his court: [/F, in Python-Dev mail] mal has reviewed the patch, and is waiting for an update from me. ------------------------------------------------------- Date: 2000-Aug-24 04:37 By: lemburg Comment: I'd rather see this patch postponed. Reason: We're not in a hury here -- better get this done right than to quickly throw together a set of patches without some more extensive testing. Comment for future reference: --------------------- Note that I would also like to unify the different Unicode databases (ctype DBs, Unicode DB and Unicode name DB) into one single unicodedb access module which will be written in Python. The sibling C modules can then be loaded dynamically and in a lazy fashion. This will result in an implementation which should be much easier to maintain than the current (2.0) setup. ------------------------------------------------------- Date: 2000-Aug-28 11:55 By: effbot Comment: postponed, for now. I'm still working on the full unidb package, and will reopen this patch again when I've fixed the other things that needs to be fixed before 2.0b1. ------------------------------------------------------- Date: 2000-Sep-23 21:10 By: tim_one Comment: Changed status to Postponed, to match the last thing that was said about it (a month ago). ------------------------------------------------------- Date: 2000-Oct-26 13:58 By: gvanrossum Comment: We did something else in 2.0 which is good enough. And Fredrik's URL doesn't resolve anymore anyway. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100899&group_id=5470 From noreply@sourceforge.net Thu Oct 26 22:13:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Oct 2000 14:13:17 -0700 Subject: [Patches] [Patch #100938] [Draft] libpython as shared library (.so) on Linux Message-ID: <200010262113.OAA30222@sf-web2.i.sourceforge.net> Patch #100938 has been updated. Project: python Category: None Status: Open Summary: [Draft] libpython as shared library (.so) on Linux Follow-Ups: Date: 2000-Jul-19 14:10 By: flight Comment: This is what it used in product to build libpython as shared library(.so) for Debian. Note: This patch is not ready for inclusion in the upstream Python distribution. Anyway, I think this might be a start. The Python 1.5 executable in Debian GNU/Linux is built against a shared libpython1.5.so since April 1999, and I haven't yet heard about any problems. Using a shared library should have an advantage if you're running multiple instances of Python (be it standalone interpreter or embedded applications). ------------------------------------------------------- Date: 2000-Aug-15 10:52 By: tim_one Comment: Assigned to Barry because he's a Linux weenie. Barry, if you think there's something here that should go into 2.0, please pursue it now, else change the status to Postponed. ------------------------------------------------------- Date: 2000-Aug-16 00:40 By: moshez Comment: I suggest we postpone it. It isn't really complete (only works on real distributions ), and the complete solution should work on all unices. If Tcl/Perl can do it, there is no reason Python can't -- and a half hearted solution isn't that good. flight, you should use this for the Python in woody in the mean time -- I doubt woody will be stable before Python 2.1 comes out, so 2.1 sounds like a good timeframe to do it. ------------------------------------------------------- Date: 2000-Aug-23 09:26 By: jhylton Comment: In the absence of anyone arguing for inclusion of this patch and a one-week idle period, it is postponed. ------------------------------------------------------- Date: 2000-Oct-26 14:13 By: gvanrossum Comment: Let's give this to Jeremy instead, because he seems to know more about build issues. Jeremy, it would be good to look into getting this to work with your RPM suite. Flight's argument (has been used without complaints in Debian Python 1.5.2 since 1999) is good. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100938&group_id=5470 From effbot@telia.com Thu Oct 26 22:41:00 2000 From: effbot@telia.com (Fredrik Lundh) Date: Thu, 26 Oct 2000 23:41:00 +0200 Subject: [Patches] Re: [Patch #100899] a smaller unicode name database References: <200010262058.NAA29848@sf-web2.i.sourceforge.net> Message-ID: <002801c03f95$6f8ccf70$3c6340d5@hagrid> > Date: 2000-Oct-26 13:58 > By: gvanrossum > > Comment: > We did something else in 2.0 which is good enough. > And Fredrik's URL doesn't resolve anymore anyway. footnote: the 2.0 work included everything from my unidb project, *except* this part. but leave it closed; I have plenty of time to whip up a new version of the patch before 2.1. From noreply@sourceforge.net Fri Oct 27 12:08:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Oct 2000 04:08:52 -0700 Subject: [Patches] [Patch #101022] Removal of SET_LINENO (experimental) Message-ID: <200010271108.EAA11307@sf-web2.i.sourceforge.net> Patch #101022 has been updated. Project: python Category: core (C code) Status: Open Summary: Removal of SET_LINENO (experimental) Follow-Ups: Date: 2000-Jul-30 16:12 By: marangoz Comment: For testing, as discussed on python-dev. For a gentle summary, see: http://www.python.org/pipermail/python-dev/2000-July/014364.html ------------------------------------------------------- Date: 2000-Jul-30 18:16 By: marangoz Comment: A nit: inline the argfetch in CALL_TRACE and goto the switch, instead of jumping to get_oparg which splits the sequence [fetch opcode, fetch oparg] -- this can slow things down. ------------------------------------------------------- Date: 2000-Jul-31 06:40 By: gvanrossum Comment: Status set to postponed to indicate that this is still experimental. ------------------------------------------------------- Date: 2000-Jul-31 07:57 By: marangoz Comment: Another rewrite, making this whole strategy b/w compatible according to the 1st incompatibility point a) described in: http://www.python.org/pipermail/python-dev/2000-July/014364.html Changes: 1. f.f_lineno is computed and updated on f_lineno attribute requests for f, given f.f_lasti. Correctness is ensured because f.f_lasti is updated on *all* attribute accesses (in LOAD_ATTR in the main loop). 2. The standard setup does not generate SET_LINENO, but uses co_lnotab for computing the source line number (e.g. tracebacks) This is equivalent to the actual "python -O". 3. With "python -d", we fall back to the current version of the interpreter (with SET_LINENO) thus making it easy to test whether this patch fully replaces SET_LINENO's behavior. (modulo f->f_lineno accesses from legacy C code, but this is insane). IMO, this version already worths the pain to be truly tested and improved. One improvement is to define a nicer public C API for breakpoints: - PyCode_SetBreakPointAtLine(line) - PyCode_SetBreakPointAtAddr(addr) or similar, which would install a CALL_TRACE opcode in the appropriate location of the copy of co_code. Another idea is to avoid duplicating the entire co_code just for storing the CALL_TRACE opcodes. We can store them in the original and keep a table of breakpoints. Setting the breakpoints would occur whenever the sys.settrace hook is set. ------------------------------------------------------- Date: 2000-Jul-31 10:50 By: marangoz Comment: A last tiny fix of the SET_LINENO opcode for better b/w compatibility. Stopping here and entering standby mode for reactions & feedback. PS: the last idea about not duplicating co_code and tweaking the original with CALL_TRACE is a bad one. I remember Guido being against it because co_code could be used elsewhere (copied, written to disk, whatever) and he's right! Better operate on an internal copy created in ceval. ------------------------------------------------------- Date: 2000-Aug-03 12:22 By: marangoz Comment: Fix missing DECREF on error condition in start_tracing() + some renaming. ------------------------------------------------------- Date: 2000-Oct-25 13:56 By: gvanrossum Comment: Vladimir, are you there? The patch doesn't apply cleanly to the current CVS tree any more... ------------------------------------------------------- Date: 2000-Oct-25 17:42 By: marangoz Comment: noreply@sourceforge.net wrote: > > Date: 2000-Oct-25 13:56 > By: gvanrossum > > Comment: > Vladimir, are you there? So-so :) I'm a moving target, checking my mail occasionally these days. Luckily, today is one of these days. > > The patch doesn't apply cleanly to the current CVS tree any more... Ah, this one's easy. Here's an update relative to 2.0 final, not CVS. I got some r/w access error trying to update my CVS copy from SF that I have no time to investigate right now... The Web interface still works though :) ------------------------------------------------------- Date: 2000-Oct-27 04:08 By: marangoz Comment: Oops, the last patch update does not contain the f.f_lineno computation in frame_getattr. This is necessary, cf. the following messages: http://www.python.org/pipermail/python-dev/2000-July/014395.html http://www.python.org/pipermail/python-dev/2000-July/014401.html Patch assigned to Guido, for review or further assignment. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101022&group_id=5470 From noreply@sourceforge.net Fri Oct 27 12:08:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Oct 2000 04:08:52 -0700 Subject: [Patches] [Patch #101022] Removal of SET_LINENO (experimental) Message-ID: <200010271108.EAA11311@sf-web2.i.sourceforge.net> Patch #101022 has been updated. Project: python Category: core (C code) Status: Open Summary: Removal of SET_LINENO (experimental) Follow-Ups: Date: 2000-Jul-30 16:12 By: marangoz Comment: For testing, as discussed on python-dev. For a gentle summary, see: http://www.python.org/pipermail/python-dev/2000-July/014364.html ------------------------------------------------------- Date: 2000-Jul-30 18:16 By: marangoz Comment: A nit: inline the argfetch in CALL_TRACE and goto the switch, instead of jumping to get_oparg which splits the sequence [fetch opcode, fetch oparg] -- this can slow things down. ------------------------------------------------------- Date: 2000-Jul-31 06:40 By: gvanrossum Comment: Status set to postponed to indicate that this is still experimental. ------------------------------------------------------- Date: 2000-Jul-31 07:57 By: marangoz Comment: Another rewrite, making this whole strategy b/w compatible according to the 1st incompatibility point a) described in: http://www.python.org/pipermail/python-dev/2000-July/014364.html Changes: 1. f.f_lineno is computed and updated on f_lineno attribute requests for f, given f.f_lasti. Correctness is ensured because f.f_lasti is updated on *all* attribute accesses (in LOAD_ATTR in the main loop). 2. The standard setup does not generate SET_LINENO, but uses co_lnotab for computing the source line number (e.g. tracebacks) This is equivalent to the actual "python -O". 3. With "python -d", we fall back to the current version of the interpreter (with SET_LINENO) thus making it easy to test whether this patch fully replaces SET_LINENO's behavior. (modulo f->f_lineno accesses from legacy C code, but this is insane). IMO, this version already worths the pain to be truly tested and improved. One improvement is to define a nicer public C API for breakpoints: - PyCode_SetBreakPointAtLine(line) - PyCode_SetBreakPointAtAddr(addr) or similar, which would install a CALL_TRACE opcode in the appropriate location of the copy of co_code. Another idea is to avoid duplicating the entire co_code just for storing the CALL_TRACE opcodes. We can store them in the original and keep a table of breakpoints. Setting the breakpoints would occur whenever the sys.settrace hook is set. ------------------------------------------------------- Date: 2000-Jul-31 10:50 By: marangoz Comment: A last tiny fix of the SET_LINENO opcode for better b/w compatibility. Stopping here and entering standby mode for reactions & feedback. PS: the last idea about not duplicating co_code and tweaking the original with CALL_TRACE is a bad one. I remember Guido being against it because co_code could be used elsewhere (copied, written to disk, whatever) and he's right! Better operate on an internal copy created in ceval. ------------------------------------------------------- Date: 2000-Aug-03 12:22 By: marangoz Comment: Fix missing DECREF on error condition in start_tracing() + some renaming. ------------------------------------------------------- Date: 2000-Oct-25 13:56 By: gvanrossum Comment: Vladimir, are you there? The patch doesn't apply cleanly to the current CVS tree any more... ------------------------------------------------------- Date: 2000-Oct-25 17:42 By: marangoz Comment: noreply@sourceforge.net wrote: > > Date: 2000-Oct-25 13:56 > By: gvanrossum > > Comment: > Vladimir, are you there? So-so :) I'm a moving target, checking my mail occasionally these days. Luckily, today is one of these days. > > The patch doesn't apply cleanly to the current CVS tree any more... Ah, this one's easy. Here's an update relative to 2.0 final, not CVS. I got some r/w access error trying to update my CVS copy from SF that I have no time to investigate right now... The Web interface still works though :) ------------------------------------------------------- Date: 2000-Oct-27 04:08 By: marangoz Comment: Oops, the last patch update does not contain the f.f_lineno computation in frame_getattr. This is necessary, cf. the following messages: http://www.python.org/pipermail/python-dev/2000-July/014395.html http://www.python.org/pipermail/python-dev/2000-July/014401.html Patch assigned to Guido, for review or further assignment. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101022&group_id=5470 From noreply@sourceforge.net Fri Oct 27 12:56:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Oct 2000 04:56:12 -0700 Subject: [Patches] [Patch #101980] Fix for #117278: Do not release unallocated Tcl objects Message-ID: <200010271156.EAA12108@sf-web2.i.sourceforge.net> Patch #101980 has been updated. Project: python Category: Tkinter Status: Open Summary: Fix for #117278: Do not release unallocated Tcl objects Follow-Ups: Date: 2000-Oct-19 14:06 By: loewis Comment: Tcl's decref does not check for null pointers. This patch releases only successfully allocated objects. ------------------------------------------------------- Date: 2000-Oct-19 20:23 By: fdrake Comment: Slightly simplified the patch, and avoid setting objc to zero twice when no intervening value was possible. Martin, if you're happy this change, go ahead and check it in and close the associated bug report. ------------------------------------------------------- Date: 2000-Oct-27 04:56 By: gvanrossum Comment: OK, let me look at this! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101980&group_id=5470 From noreply@sourceforge.net Fri Oct 27 13:18:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Oct 2000 05:18:25 -0700 Subject: [Patches] [Patch #101980] Fix for #117278: Do not release unallocated Tcl objects Message-ID: <200010271218.FAA09688@sf-web1.i.sourceforge.net> Patch #101980 has been updated. Project: python Category: Tkinter Status: Accepted Summary: Fix for #117278: Do not release unallocated Tcl objects Follow-Ups: Date: 2000-Oct-19 14:06 By: loewis Comment: Tcl's decref does not check for null pointers. This patch releases only successfully allocated objects. ------------------------------------------------------- Date: 2000-Oct-19 20:23 By: fdrake Comment: Slightly simplified the patch, and avoid setting objc to zero twice when no intervening value was possible. Martin, if you're happy this change, go ahead and check it in and close the associated bug report. ------------------------------------------------------- Date: 2000-Oct-27 04:56 By: gvanrossum Comment: OK, let me look at this! ------------------------------------------------------- Date: 2000-Oct-27 05:18 By: gvanrossum Comment: Looks good. Martin, please check it in, close it, and close the 2 bug reports! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101980&group_id=5470 From noreply@sourceforge.net Sat Oct 28 14:41:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 28 Oct 2000 06:41:56 -0700 Subject: [Patches] [Patch #101972] Fix for lookbehind bug (#117242) Message-ID: <200010281341.GAA31203@sf-web1.i.sourceforge.net> Patch #101972 has been updated. Project: python Category: library Status: Accepted Summary: Fix for lookbehind bug (#117242) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101972&group_id=5470 From noreply@sourceforge.net Sat Oct 28 20:02:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 28 Oct 2000 12:02:10 -0700 Subject: [Patches] [Patch #101972] Fix for lookbehind bug (#117242) Message-ID: <200010281902.MAA02001@sf-web3.vaspecialprojects.com> Patch #101972 has been updated. Project: python Category: library Status: Closed Summary: Fix for lookbehind bug (#117242) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101972&group_id=5470 From noreply@sourceforge.net Sun Oct 29 01:45:20 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 28 Oct 2000 17:45:20 -0700 Subject: [Patches] [Patch #101980] Fix for #117278: Do not release unallocated Tcl objects Message-ID: <200010290045.RAA17357@sf-web2.i.sourceforge.net> Patch #101980 has been updated. Project: python Category: Tkinter Status: Closed Summary: Fix for #117278: Do not release unallocated Tcl objects Follow-Ups: Date: 2000-Oct-19 14:06 By: loewis Comment: Tcl's decref does not check for null pointers. This patch releases only successfully allocated objects. ------------------------------------------------------- Date: 2000-Oct-19 20:23 By: fdrake Comment: Slightly simplified the patch, and avoid setting objc to zero twice when no intervening value was possible. Martin, if you're happy this change, go ahead and check it in and close the associated bug report. ------------------------------------------------------- Date: 2000-Oct-27 04:56 By: gvanrossum Comment: OK, let me look at this! ------------------------------------------------------- Date: 2000-Oct-27 05:18 By: gvanrossum Comment: Looks good. Martin, please check it in, close it, and close the 2 bug reports! ------------------------------------------------------- Date: 2000-Oct-28 17:45 By: loewis Comment: Committed as _tkinter.c 1.114 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101980&group_id=5470 From noreply@sourceforge.net Mon Oct 30 12:24:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Oct 2000 04:24:21 -0800 Subject: [Patches] [Patch #101186] IPv6 support in 1.6b1 (1.5.2 also available at ftp.kame.net) - from core@kame.net Message-ID: <200010301224.EAA25159@sf-web2.i.sourceforge.net> Patch #101186 has been updated. Project: python Category: Modules Status: Out of date Summary: IPv6 support in 1.6b1 (1.5.2 also available at ftp.kame.net) - from core@kame.net Follow-Ups: Date: 2000-Aug-15 09:18 By: twouters Comment: This looks like PEP material. We actually discussed this briefly on python-dev, but there was noone there that had both the time and the knowledge to persue this. (I looked briefly at the 1.5.2 IPv6 implementation, but it raised too many questions to be added 'just like that', IMHO.) Would anyone from the team that wrote this feel like writing a PEP ? How involved are you in Python ? In absense of a volunteer to write a PEP, would there be a volunteer to explain design decisions ? (Hm, the person who submitted this patch did so anonymously. I'll forward the summary of this patch to core@kame.net) ------------------------------------------------------- Date: 2000-Aug-15 09:31 By: fdrake Comment: This will not go in Python 1.6. Python 2.0 is also closed for new features, so this should be taken up with Tim & Guido for 2.0. There is no good reason not to include this feature in Python 2.1; but I can't speak for the quality of the patch until I've had time to review it. Perhaps Python developers & testers knowledgable about IPv6 should get in touch with the person this patch is assigned to. ------------------------------------------------------- Date: 2000-Aug-15 15:30 By: tim_one Comment: Changed status to Postponed because it came in after 2.0 feature freeze. If you make a huge stink on Python-Dev and get a lot of support, cool, I'll re-Open it. Else it's for 2.1 at the earliest. ------------------------------------------------------- Date: 2000-Oct-30 04:24 By: twouters Comment: A newer version of this patch can be found as patch #101196, assigned to fdrake. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101186&group_id=5470 From noreply@sourceforge.net Mon Oct 30 13:01:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Oct 2000 05:01:08 -0800 Subject: [Patches] [Patch #102169] Additional docs for __iadd__ hooks Message-ID: <200010301301.FAA06899@sf-web1.i.sourceforge.net> Patch #102169 has been updated. Project: python Category: documentation Status: Open Summary: Additional docs for __iadd__ hooks ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102169&group_id=5470 From noreply@sourceforge.net Mon Oct 30 13:02:20 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Oct 2000 05:02:20 -0800 Subject: [Patches] [Patch #102169] Additional docs for __iadd__ hooks Message-ID: <200010301302.FAA06917@sf-web1.i.sourceforge.net> Patch #102169 has been updated. Project: python Category: documentation Status: Open Summary: Additional docs for __iadd__ hooks Follow-Ups: Date: 2000-Oct-30 05:02 By: twouters Comment: 'Fix' for 'bug' #117178: add description of the in-place hooks to the Reference manual, section 3.3. Untested TeX code, but likely to be correct (mostly copy-and-paste work.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102169&group_id=5470 From noreply@sourceforge.net Mon Oct 30 14:44:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Oct 2000 06:44:31 -0800 Subject: [Patches] [Patch #101664] Add new unistr() builtin + PyObject_Unicode() C API Message-ID: <200010301444.GAA08522@sf-web1.i.sourceforge.net> Patch #101664 has been updated. Project: python Category: core (C code) Status: Open Summary: Add new unistr() builtin + PyObject_Unicode() C API Follow-Ups: Date: 2000-Sep-26 04:14 By: lemburg Comment: This patch adds a utility function unistr() which works just like the standard builtin str() -- only that the return value will always be a Unicode object. The patch also adds a new object level C API PyObject_Unicode() which complements PyObject_Str(). Since this is a new feature, I have postponed the patch to be reopened in the 2.1 cycle. ------------------------------------------------------- Date: 2000-Oct-30 06:44 By: moshez Comment: There is no documentation for unistr() and PyObject_Unicode(), which is usually considered a show stopper by the powers that be. Here's some draft docos Insert into Doc/libfuncs.tex, after \begin{funcdesc}{str}....\end{funcdesc}: \begin{funcdesc}{unistr}{object} Return a Unicode representation of an object. It returns the result of converting the str(object) to unicode if the object can be converted into a string. It returns unicode objects as is. \end{funcdesc} Insert the following in Doc/api/api.tex after \begin{cfuncdesc}{PyObject*}{PyObject_Str}{PyObject *o}...\end{cfuncdesc} \begin{cfuncdesc}{PyObject *}{PyObject_Unicode}{PyObject *O} Compute a unicode representation of \var{o}. Returns the unicode representation on success \NULL{} on failure. This is the equivalent of the Python expression \samp{unistr(\var{o})}. Called by the \function{unistr()}\bifuncindex{unistr} built-in function. \end{cfuncdesc} Oh, and please don't use PyObject_GetAttrString: It's slow.... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101664&group_id=5470 From noreply@sourceforge.net Mon Oct 30 15:19:51 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Oct 2000 07:19:51 -0800 Subject: [Patches] [Patch #101664] Add new unistr() builtin + PyObject_Unicode() C API Message-ID: <200010301519.HAA29292@sf-web2.i.sourceforge.net> Patch #101664 has been updated. Project: python Category: core (C code) Status: Open Summary: Add new unistr() builtin + PyObject_Unicode() C API Follow-Ups: Date: 2000-Sep-26 04:14 By: lemburg Comment: This patch adds a utility function unistr() which works just like the standard builtin str() -- only that the return value will always be a Unicode object. The patch also adds a new object level C API PyObject_Unicode() which complements PyObject_Str(). Since this is a new feature, I have postponed the patch to be reopened in the 2.1 cycle. ------------------------------------------------------- Date: 2000-Oct-30 06:44 By: moshez Comment: There is no documentation for unistr() and PyObject_Unicode(), which is usually considered a show stopper by the powers that be. Here's some draft docos Insert into Doc/libfuncs.tex, after \begin{funcdesc}{str}....\end{funcdesc}: \begin{funcdesc}{unistr}{object} Return a Unicode representation of an object. It returns the result of converting the str(object) to unicode if the object can be converted into a string. It returns unicode objects as is. \end{funcdesc} Insert the following in Doc/api/api.tex after \begin{cfuncdesc}{PyObject*}{PyObject_Str}{PyObject *o}...\end{cfuncdesc} \begin{cfuncdesc}{PyObject *}{PyObject_Unicode}{PyObject *O} Compute a unicode representation of \var{o}. Returns the unicode representation on success \NULL{} on failure. This is the equivalent of the Python expression \samp{unistr(\var{o})}. Called by the \function{unistr()}\bifuncindex{unistr} built-in function. \end{cfuncdesc} Oh, and please don't use PyObject_GetAttrString: It's slow.... ------------------------------------------------------- Date: 2000-Oct-30 07:19 By: none Comment: Thanks. I'll add the docs to the patch. About PyObject_GetAttrString() ... I'll add an optimization somewhat like in classobject.c to PyObject_Unicode() which should help boost the performance somewhat. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101664&group_id=5470 From noreply@sourceforge.net Mon Oct 30 15:19:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Oct 2000 07:19:50 -0800 Subject: [Patches] [Patch #101664] Add new unistr() builtin + PyObject_Unicode() C API Message-ID: <200010301519.HAA29289@sf-web2.i.sourceforge.net> Patch #101664 has been updated. Project: python Category: core (C code) Status: Open Summary: Add new unistr() builtin + PyObject_Unicode() C API Follow-Ups: Date: 2000-Sep-26 04:14 By: lemburg Comment: This patch adds a utility function unistr() which works just like the standard builtin str() -- only that the return value will always be a Unicode object. The patch also adds a new object level C API PyObject_Unicode() which complements PyObject_Str(). Since this is a new feature, I have postponed the patch to be reopened in the 2.1 cycle. ------------------------------------------------------- Date: 2000-Oct-30 06:44 By: moshez Comment: There is no documentation for unistr() and PyObject_Unicode(), which is usually considered a show stopper by the powers that be. Here's some draft docos Insert into Doc/libfuncs.tex, after \begin{funcdesc}{str}....\end{funcdesc}: \begin{funcdesc}{unistr}{object} Return a Unicode representation of an object. It returns the result of converting the str(object) to unicode if the object can be converted into a string. It returns unicode objects as is. \end{funcdesc} Insert the following in Doc/api/api.tex after \begin{cfuncdesc}{PyObject*}{PyObject_Str}{PyObject *o}...\end{cfuncdesc} \begin{cfuncdesc}{PyObject *}{PyObject_Unicode}{PyObject *O} Compute a unicode representation of \var{o}. Returns the unicode representation on success \NULL{} on failure. This is the equivalent of the Python expression \samp{unistr(\var{o})}. Called by the \function{unistr()}\bifuncindex{unistr} built-in function. \end{cfuncdesc} Oh, and please don't use PyObject_GetAttrString: It's slow.... ------------------------------------------------------- Date: 2000-Oct-30 07:19 By: none Comment: Thanks. I'll add the docs to the patch. About PyObject_GetAttrString() ... I'll add an optimization somewhat like in classobject.c to PyObject_Unicode() which should help boost the performance somewhat. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101664&group_id=5470 From noreply@sourceforge.net Mon Oct 30 17:43:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Oct 2000 09:43:03 -0800 Subject: [Patches] [Patch #102170] move getopt() to Py_GetOpt() and use it unconditionally Message-ID: <200010301743.JAA11416@sf-web1.i.sourceforge.net> Patch #102170 has been updated. Project: python Category: core (C code) Status: Open Summary: move getopt() to Py_GetOpt() and use it unconditionally ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102170&group_id=5470 From noreply@sourceforge.net Mon Oct 30 17:48:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Oct 2000 09:48:55 -0800 Subject: [Patches] [Patch #102170] move getopt() to Py_GetOpt() and use it unconditionally Message-ID: <200010301748.JAA11504@sf-web1.i.sourceforge.net> Patch #102170 has been updated. Project: python Category: core (C code) Status: Open Summary: move getopt() to Py_GetOpt() and use it unconditionally Follow-Ups: Date: 2000-Oct-30 09:48 By: twouters Comment: This patch attempts to do what Tim suggested in the python-dev thread about getopt()'s prototype and the difficulties of it. the 'getopt' implementation as provided in Python/getopt.c is renamed to Py_GetOpt(), the exported variables 'opterr', 'optind' and 'optarg' are prefixed with Py_, and all use in the Python sourcetree is adjusted. The patch is missing the 'pygetopt.h' include file, though :P I'll resubmit a proper patch later. There are a couple of issues still open: the name of the getopt.c file, its use of 'fprintf(stderr, ... )', its license, documentation (which this patch lacks) and whether this Py_GetOpt should be an officially exported API at all. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102170&group_id=5470 From noreply@sourceforge.net Mon Oct 30 18:08:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Oct 2000 10:08:49 -0800 Subject: [Patches] [Patch #102170] move getopt() to Py_GetOpt() and use it unconditionally Message-ID: <200010301808.KAA01101@sf-web2.i.sourceforge.net> Patch #102170 has been updated. Project: python Category: core (C code) Status: Open Summary: move getopt() to Py_GetOpt() and use it unconditionally Follow-Ups: Date: 2000-Oct-30 09:48 By: twouters Comment: This patch attempts to do what Tim suggested in the python-dev thread about getopt()'s prototype and the difficulties of it. the 'getopt' implementation as provided in Python/getopt.c is renamed to Py_GetOpt(), the exported variables 'opterr', 'optind' and 'optarg' are prefixed with Py_, and all use in the Python sourcetree is adjusted. The patch is missing the 'pygetopt.h' include file, though :P I'll resubmit a proper patch later. There are a couple of issues still open: the name of the getopt.c file, its use of 'fprintf(stderr, ... )', its license, documentation (which this patch lacks) and whether this Py_GetOpt should be an officially exported API at all. ------------------------------------------------------- Date: 2000-Oct-30 10:08 By: twouters Comment: New patch, includes pygetopt.h by hack. (not sure if it patches cleanly, but it's not that exciting a file anyway :) Assigned to.... (spin wheel... Guido. no. spin wheel... Barry. no. spin wheel... Moshe. dang. spin wheel... *nudge*. Ah, finally,) Tim. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102170&group_id=5470 From noreply@sourceforge.net Tue Oct 31 16:35:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Oct 2000 08:35:32 -0800 Subject: [Patches] [Patch #102185] reclaim fds in smtplib.py on connect failures Message-ID: <200010311635.IAA31889@sf-web3.vaspecialprojects.com> Patch #102185 has been updated. Project: python Category: library Status: Open Summary: reclaim fds in smtplib.py on connect failures ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102185&group_id=5470 From noreply@sourceforge.net Tue Oct 31 16:38:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Oct 2000 08:38:10 -0800 Subject: [Patches] [Patch #102185] reclaim fds in smtplib.py on connect failures Message-ID: <200010311638.IAA29597@sf-web2.i.sourceforge.net> Patch #102185 has been updated. Project: python Category: library Status: Open Summary: reclaim fds in smtplib.py on connect failures Follow-Ups: Date: 2000-Oct-31 08:38 By: bwarsaw Comment: This patch fixes bug #119883 where failures in SMTP.connect() during the socket.connect() will leak file descriptors. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102185&group_id=5470