From noreply@sourceforge.net Tue Oct 1 00:48:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Sep 2002 16:48:34 -0700 Subject: [Patches] [ python-Patches-594001 ] PEP 277: Unicode file name support Message-ID: Patches item #594001, was opened at 2002-08-12 21:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Martin v. Löwis (loewis) Summary: PEP 277: Unicode file name support Initial Comment: This patch is in an updated version of the patch [1] mentioned in the PEP. In addition to merging it with the CVS, it fixes a few formatting problems. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2002-10-01 09:48 Message: Logged In: YES user_id=14198 Although SF implies otherwise, a bad filename in a submission appears to only prevent the file being uploaded - the rest of the comments etc come through. Hence my double-comments and strange status changes you can see. So, back to Martin as I don't think he is waiting on me for anything. Happy to check in if you like, but would like to see someone run a debug build of this through Linux first to see if any asserts fire - some asserts did indeed fire in the first version of this patch, and Linux may trigger others, or even the 2 that I added. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:54 Message: Logged In: YES user_id=14198 Sorry - not sure what I was thinking - obviously can't check in a patch known to crash the test suite! Attaching a new patch - fixes the problem I mentioned with test_unicode_files.py, fixes an error I introduced where the "WithFilename" error functions could be passed a NULL filename, and adding an assert to match the one I added previously. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:52 Message: Logged In: YES user_id=14198 Sorry - not sure what I was thinking - obviously can't check in a patch known to crash the test suite! Attaching a new patch. This fixes the crash in test_unicode_file I mentioned. It also fixes another error I introduced where PyErr_SetWithFilename functions can have NULL filenames. Also added an assert for symmetry with one I added before. Martin - back to me if you want me to check it in. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:21 Message: Logged In: YES user_id=14198 I missed the fact this was re-assigned to me - should I check my new patch in? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:20 Message: Logged In: YES user_id=14198 I get an exception running test_unicode_file.py - we end up with a MBCS encoded string passed to PyUnicode_FromEncodedObject(), that attempts to decode using the system default encoding rather than the file-system default. The error is a NULL pointer deref so should be obvious - unfortunately the fix requires a local reimplementation of PyUnicode_FromEncodedObject(), passing an explicit encoding for string objects. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 20:43 Message: Logged In: YES user_id=21627 Thanks for your comments, just shouting at me to correct all these problems would have been fine :-) In what case do you still get an exception? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:35 Message: Logged In: YES user_id=14198 Back to martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:34 Message: Logged In: YES user_id=14198 Back to Martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:33 Message: Logged In: YES user_id=14198 Uploading text file with my comments on the patch. Also uploading a new patch with these corrections and even better (?) error handling. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 11:03 Message: Logged In: YES user_id=14198 Will review this instant - sorry for the delay. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 16:24 Message: Logged In: YES user_id=21627 Mark, can you please indicate whether you will review this patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-26 05:43 Message: Logged In: YES user_id=31435 Sorry, Martin, bouncing back to Mark -- I really don't know anything about the Windows filename APIs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-23 01:31 Message: Logged In: YES user_id=21627 Tim, can you review this? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 22:06 Message: Logged In: YES user_id=21627 This is a new version: - wrapped all Windows wide API code with #ifdef Py_WIN_WIDE_FILENAMES - added test case Mark, can you please take a look at this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-12 23:38 Message: Logged In: YES user_id=6380 I'd make unicode_filenames() a macro that expands to 0 on platforms without this wart. I'd also test for wfunc!=NULL before calling unicode_filenames(). There's a lot of hairy code here. Are you sure that there are test cases in the test suite that exercise all of it? Aren't there some #ifdefs missing? posix_[12]str have code that's only relevant for Windows but isn't #ifdef'ed out like it is elsewhere. There should probably be a separate #define in pyport.h to test for this that's equivalent to defined(MS_WINDOWS) && !defined(Py_UNICODE_WIDE), so this can be uniformly tested to see whether this code is necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 From noreply@sourceforge.net Tue Oct 1 05:21:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Sep 2002 21:21:13 -0700 Subject: [Patches] [ python-Patches-603831 ] ccompiler argument checking too strict Message-ID: Patches item #603831, was opened at 2002-09-03 01:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=603831&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Moshe Zadka (moshez) >Assigned to: Guido van Rossum (gvanrossum) Summary: ccompiler argument checking too strict Initial Comment: ccompiler's argument checking prevents the check_header functionality. The patch found in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=159288&repeatmerged=yes is a workaround -- there are possibly better workarounds, but this one is easy and works. Thanks. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-01 00:21 Message: Logged In: YES user_id=6380 I don't know what to think of this; of the three patch chunks in the attached "diff" file, the last two (that Andrew said were needed) were already in CVS; but the one chunk that Moshe suggested in the debian bug report was not checked in. I've checked this in now. I think it is *not* a bugfix candidate; the Twisted build procedure only failed with 2.3, it passed with 2.2 and 2.1 so there must be some other change in 2.3 that broke this functionality (possible the default value for self.output_dir was changed, but I am not familiar enough with this codebase to know.) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-09-05 09:45 Message: Logged In: YES user_id=11375 After some more poking, I think the following other two changes are needed (providing a body to try_cpp(), and using the source file name in preprocess()). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-09-05 09:30 Message: Logged In: YES user_id=11375 The patch looks fine to me; feel free to check it in. (Should probably mark it a bugfix candidate.) However, can you provide an example setup.py? With the suggested patch, check_header() still fails for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=603831&group_id=5470 From noreply@sourceforge.net Tue Oct 1 10:59:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 01 Oct 2002 02:59:47 -0700 Subject: [Patches] [ python-Patches-594001 ] PEP 277: Unicode file name support Message-ID: Patches item #594001, was opened at 2002-08-12 21:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Martin v. Löwis (loewis) Summary: PEP 277: Unicode file name support Initial Comment: This patch is in an updated version of the patch [1] mentioned in the PEP. In addition to merging it with the CVS, it fixes a few formatting problems. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2002-10-01 19:59 Message: Logged In: YES user_id=14198 The block: + if (!wpath1 || !wpath2) + return NULL; Should include Py_XDECREF calls for wpath1 and wpath2. Can't be bothered with a new patch just for this :) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-01 09:48 Message: Logged In: YES user_id=14198 Although SF implies otherwise, a bad filename in a submission appears to only prevent the file being uploaded - the rest of the comments etc come through. Hence my double-comments and strange status changes you can see. So, back to Martin as I don't think he is waiting on me for anything. Happy to check in if you like, but would like to see someone run a debug build of this through Linux first to see if any asserts fire - some asserts did indeed fire in the first version of this patch, and Linux may trigger others, or even the 2 that I added. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:54 Message: Logged In: YES user_id=14198 Sorry - not sure what I was thinking - obviously can't check in a patch known to crash the test suite! Attaching a new patch - fixes the problem I mentioned with test_unicode_files.py, fixes an error I introduced where the "WithFilename" error functions could be passed a NULL filename, and adding an assert to match the one I added previously. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:52 Message: Logged In: YES user_id=14198 Sorry - not sure what I was thinking - obviously can't check in a patch known to crash the test suite! Attaching a new patch. This fixes the crash in test_unicode_file I mentioned. It also fixes another error I introduced where PyErr_SetWithFilename functions can have NULL filenames. Also added an assert for symmetry with one I added before. Martin - back to me if you want me to check it in. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:21 Message: Logged In: YES user_id=14198 I missed the fact this was re-assigned to me - should I check my new patch in? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:20 Message: Logged In: YES user_id=14198 I get an exception running test_unicode_file.py - we end up with a MBCS encoded string passed to PyUnicode_FromEncodedObject(), that attempts to decode using the system default encoding rather than the file-system default. The error is a NULL pointer deref so should be obvious - unfortunately the fix requires a local reimplementation of PyUnicode_FromEncodedObject(), passing an explicit encoding for string objects. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 20:43 Message: Logged In: YES user_id=21627 Thanks for your comments, just shouting at me to correct all these problems would have been fine :-) In what case do you still get an exception? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:35 Message: Logged In: YES user_id=14198 Back to martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:34 Message: Logged In: YES user_id=14198 Back to Martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:33 Message: Logged In: YES user_id=14198 Uploading text file with my comments on the patch. Also uploading a new patch with these corrections and even better (?) error handling. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 11:03 Message: Logged In: YES user_id=14198 Will review this instant - sorry for the delay. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 16:24 Message: Logged In: YES user_id=21627 Mark, can you please indicate whether you will review this patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-26 05:43 Message: Logged In: YES user_id=31435 Sorry, Martin, bouncing back to Mark -- I really don't know anything about the Windows filename APIs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-23 01:31 Message: Logged In: YES user_id=21627 Tim, can you review this? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 22:06 Message: Logged In: YES user_id=21627 This is a new version: - wrapped all Windows wide API code with #ifdef Py_WIN_WIDE_FILENAMES - added test case Mark, can you please take a look at this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-12 23:38 Message: Logged In: YES user_id=6380 I'd make unicode_filenames() a macro that expands to 0 on platforms without this wart. I'd also test for wfunc!=NULL before calling unicode_filenames(). There's a lot of hairy code here. Are you sure that there are test cases in the test suite that exercise all of it? Aren't there some #ifdefs missing? posix_[12]str have code that's only relevant for Windows but isn't #ifdef'ed out like it is elsewhere. There should probably be a separate #define in pyport.h to test for this that's equivalent to defined(MS_WINDOWS) && !defined(Py_UNICODE_WIDE), so this can be uniformly tested to see whether this code is necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 From noreply@sourceforge.net Tue Oct 1 18:41:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 01 Oct 2002 10:41:20 -0700 Subject: [Patches] [ python-Patches-594001 ] PEP 277: Unicode file name support Message-ID: Patches item #594001, was opened at 2002-08-12 13:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Mark Hammond (mhammond) Summary: PEP 277: Unicode file name support Initial Comment: This patch is in an updated version of the patch [1] mentioned in the PEP. In addition to merging it with the CVS, it fixes a few formatting problems. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-01 19:41 Message: Logged In: YES user_id=21627 The patch passes the test suite on Solaris. I've also attached a documentation change, so I think the patch is ready now. Back to Mark for checkin. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-01 11:59 Message: Logged In: YES user_id=14198 The block: + if (!wpath1 || !wpath2) + return NULL; Should include Py_XDECREF calls for wpath1 and wpath2. Can't be bothered with a new patch just for this :) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-01 01:48 Message: Logged In: YES user_id=14198 Although SF implies otherwise, a bad filename in a submission appears to only prevent the file being uploaded - the rest of the comments etc come through. Hence my double-comments and strange status changes you can see. So, back to Martin as I don't think he is waiting on me for anything. Happy to check in if you like, but would like to see someone run a debug build of this through Linux first to see if any asserts fire - some asserts did indeed fire in the first version of this patch, and Linux may trigger others, or even the 2 that I added. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 14:54 Message: Logged In: YES user_id=14198 Sorry - not sure what I was thinking - obviously can't check in a patch known to crash the test suite! Attaching a new patch - fixes the problem I mentioned with test_unicode_files.py, fixes an error I introduced where the "WithFilename" error functions could be passed a NULL filename, and adding an assert to match the one I added previously. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 14:52 Message: Logged In: YES user_id=14198 Sorry - not sure what I was thinking - obviously can't check in a patch known to crash the test suite! Attaching a new patch. This fixes the crash in test_unicode_file I mentioned. It also fixes another error I introduced where PyErr_SetWithFilename functions can have NULL filenames. Also added an assert for symmetry with one I added before. Martin - back to me if you want me to check it in. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 14:21 Message: Logged In: YES user_id=14198 I missed the fact this was re-assigned to me - should I check my new patch in? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 14:20 Message: Logged In: YES user_id=14198 I get an exception running test_unicode_file.py - we end up with a MBCS encoded string passed to PyUnicode_FromEncodedObject(), that attempts to decode using the system default encoding rather than the file-system default. The error is a NULL pointer deref so should be obvious - unfortunately the fix requires a local reimplementation of PyUnicode_FromEncodedObject(), passing an explicit encoding for string objects. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 12:43 Message: Logged In: YES user_id=21627 Thanks for your comments, just shouting at me to correct all these problems would have been fine :-) In what case do you still get an exception? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 08:35 Message: Logged In: YES user_id=14198 Back to martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 08:34 Message: Logged In: YES user_id=14198 Back to Martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 08:33 Message: Logged In: YES user_id=14198 Uploading text file with my comments on the patch. Also uploading a new patch with these corrections and even better (?) error handling. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 03:03 Message: Logged In: YES user_id=14198 Will review this instant - sorry for the delay. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 08:24 Message: Logged In: YES user_id=21627 Mark, can you please indicate whether you will review this patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-25 21:43 Message: Logged In: YES user_id=31435 Sorry, Martin, bouncing back to Mark -- I really don't know anything about the Windows filename APIs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 17:31 Message: Logged In: YES user_id=21627 Tim, can you review this? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 14:06 Message: Logged In: YES user_id=21627 This is a new version: - wrapped all Windows wide API code with #ifdef Py_WIN_WIDE_FILENAMES - added test case Mark, can you please take a look at this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-12 15:38 Message: Logged In: YES user_id=6380 I'd make unicode_filenames() a macro that expands to 0 on platforms without this wart. I'd also test for wfunc!=NULL before calling unicode_filenames(). There's a lot of hairy code here. Are you sure that there are test cases in the test suite that exercise all of it? Aren't there some #ifdefs missing? posix_[12]str have code that's only relevant for Windows but isn't #ifdef'ed out like it is elsewhere. There should probably be a separate #define in pyport.h to test for this that's equivalent to defined(MS_WINDOWS) && !defined(Py_UNICODE_WIDE), so this can be uniformly tested to see whether this code is necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 From noreply@sourceforge.net Wed Oct 2 00:17:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 01 Oct 2002 16:17:22 -0700 Subject: [Patches] [ python-Patches-617309 ] getframe hook (Psyco #1) Message-ID: Patches item #617309, was opened at 2002-10-01 23:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617309&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: getframe hook (Psyco #1) Initial Comment: Psyco-friendly patch #1 Allow Psyco-like extension modules to quickly plug their own notion of frame call stack into Python, for the use of the interpreter's parts that rely on the call stack for context information. For example, the code that creates a new class implicitely reads the top frame's globals if the class does not explicitely defines a __module__ attribute. With this new hook, Psyco can provide such code with the expected frame object. pystate.h: The PyThreadState structure has a new field added at its end: Py_getframehook getframe; where typedef PyFrameObject *(*Py_getframehook)(PyThreadState *, int); This field points to a function that returns the nth frame object in the call stack. By default, it points to a standard function that starts with tstate->frame and walks their f_back fields, just like the implementation of sys._getframe(). The purpose of this is to allow Psyco to hook another function at this point, in order to lazily emulate the frame objects that correspond to frames executed by Psyco. sysmodule.c: sys_getframe() calls the hook. ceval.c: PyEval_GetFrame() calls the hook. various other places in ceval.c: replaced PyThreadState_Get()->frame with PyEval_GetFrame() so that the hook will be called. pyexpat.c: replaced a PyThreadState_Get()->frame->f_globals with PyEval_GetGlobals(). Note that there are other places using 'frame' and the 'f_back' pointers which have not been changed because they are concerned with actual (classical) bytecode interpretation. The hook is only used in places that are interested in obtaining contextual information (like what the previous frame's globals are), not in places that actually builds frames in which bytecode will be interpreted. Compatibility: third-party extension modules directly reading frame, like Expat before this patch, will exhibit a marginally wrong behavior with Psyco until they are modified to call the hook (or better the "official" interpreter routines that are modified to so do). It does not break anything at all as long as we are not using Psyco. Performance overhead: one more indirect call isn't heavy. More importantly, I don't expect the concerned functions to be used more than occasionally in any code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617309&group_id=5470 From noreply@sourceforge.net Wed Oct 2 00:20:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 01 Oct 2002 16:20:54 -0700 Subject: [Patches] [ python-Patches-617311 ] Tiny profiling info (Psyco #2) Message-ID: Patches item #617311, was opened at 2002-10-01 23:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617311&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Tiny profiling info (Psyco #2) Initial Comment: Psyco-friendly patch #2. A very very small statistic-collecting patch. pystate.h: added a field at the end of the PyThreadStruct: int tick_counter; ceval.c: eval_frame(): tstate->tick_counter is incremented whenever the check_interval ticker reaches zero. The purpose is to give a useful measure of the number of interpreted bytecode instructions in a given thread. This extremely lightweight statistic collector can be of interest to profilers (like psyco.jit()). We can safely guess that a single integer increment every 100 interpreted bytecode instructions will go entierely unnoticed in any performance measure. [This is true for pystone.py.] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617311&group_id=5470 From noreply@sourceforge.net Wed Oct 2 00:22:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 01 Oct 2002 16:22:46 -0700 Subject: [Patches] [ python-Patches-617309 ] getframe hook (Psyco #1) Message-ID: Patches item #617309, was opened at 2002-10-01 23:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617309&group_id=5470 >Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: getframe hook (Psyco #1) Initial Comment: Psyco-friendly patch #1 Allow Psyco-like extension modules to quickly plug their own notion of frame call stack into Python, for the use of the interpreter's parts that rely on the call stack for context information. For example, the code that creates a new class implicitely reads the top frame's globals if the class does not explicitely defines a __module__ attribute. With this new hook, Psyco can provide such code with the expected frame object. pystate.h: The PyThreadState structure has a new field added at its end: Py_getframehook getframe; where typedef PyFrameObject *(*Py_getframehook)(PyThreadState *, int); This field points to a function that returns the nth frame object in the call stack. By default, it points to a standard function that starts with tstate->frame and walks their f_back fields, just like the implementation of sys._getframe(). The purpose of this is to allow Psyco to hook another function at this point, in order to lazily emulate the frame objects that correspond to frames executed by Psyco. sysmodule.c: sys_getframe() calls the hook. ceval.c: PyEval_GetFrame() calls the hook. various other places in ceval.c: replaced PyThreadState_Get()->frame with PyEval_GetFrame() so that the hook will be called. pyexpat.c: replaced a PyThreadState_Get()->frame->f_globals with PyEval_GetGlobals(). Note that there are other places using 'frame' and the 'f_back' pointers which have not been changed because they are concerned with actual (classical) bytecode interpretation. The hook is only used in places that are interested in obtaining contextual information (like what the previous frame's globals are), not in places that actually builds frames in which bytecode will be interpreted. Compatibility: third-party extension modules directly reading frame, like Expat before this patch, will exhibit a marginally wrong behavior with Psyco until they are modified to call the hook (or better the "official" interpreter routines that are modified to so do). It does not break anything at all as long as we are not using Psyco. Performance overhead: one more indirect call isn't heavy. More importantly, I don't expect the concerned functions to be used more than occasionally in any code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617309&group_id=5470 From noreply@sourceforge.net Wed Oct 2 00:26:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 01 Oct 2002 16:26:54 -0700 Subject: [Patches] [ python-Patches-617312 ] debugger-controlled jumps (Psyco #3) Message-ID: Patches item #617312, was opened at 2002-10-01 23:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617312&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: debugger-controlled jumps (Psyco #3) Initial Comment: Psyco-friendly patch #3. Allows the C profile and trace functions (called upon function entry, line tracing, function exit, and exception) to alter some fields of the current PyFrameObject to influence the execution of the main loop. This is currently impossible because all the relevant fields are copied into local variables of eval_frame(), shadowing any subsequence change in the frame object. This is designed for what I plan to do with Psyco, but could also be used by advanced debuggers to allow the execution point to be modified by the user. Besides, the patch is just a matter of swapping a few lines in eval_frame(), introducing almost no extra complexity. In ceval.c:eval_frame(): The calls to call_trace(...PyTrace_CALL...) at the beginning of the code have been moved above the initialization of the local variables, allowing the trace functions to fiddle with the frame object before the main loop sees it. There is also a bug fix here: if the profile or trace functions raise an error at this point, eval_frame() used to quit without restoring tstate->frame and tstate->recursion_depth. [XXX should have been a bug report on its own] Finally, the call_trace() on SET_LINENO has been slightly modified to allow the trace function to move the execution point elsewhere. This is done by saving a few local variables are saved to and restored from the frame object around the call_trace(). The variables are the current instruction pointer (which was already saved in f->f_lasti, but is now restored from f->f_lasti too), and the current stack_pointer. Compatibility: f->f_stacktop normally remains NULL for the whole execution of the frame. This patch sets it to a non-NULL value for the duration of the call to the line-by-line trace function. I expect this not to cause any incompatibility because f->f_stacktop is not visible from Python code. I do not expect extension modules to rely on this detail. Note however that this has an influence on the GC, which only visits the stack if f->f_stacktop is set. Again, I assume this is not an issue -- it cannot even cause dead cycles to be detected earlier by the GC because as long as we are in the call_trace() call, we have a live reference to f. Performance: when tracing is on, SET_LINENO is now marginally slower. I guess this is not considered as an issue given the debugging nature of tracing. In Python 2.3, line tracing is currently *much* heavier and nobody seems to complain ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617312&group_id=5470 From noreply@sourceforge.net Wed Oct 2 07:39:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 01 Oct 2002 23:39:28 -0700 Subject: [Patches] [ python-Patches-598163 ] textwrap.dedent, inspect.getdoc-ish Message-ID: Patches item #598163, was opened at 2002-08-21 12:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=598163&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ville Vainio (vvainio) Assigned to: Greg Ward (gward) Summary: textwrap.dedent, inspect.getdoc-ish Initial Comment: Ability to remove indentation from multiline strings (often triple-quoted). Differs from inspect.getdoc by not handling the first line in special manner (often a sensible approach for non-docstring multiline strings) - which should make this function more general (symmetric 'indent' also possible), and more fitting for the textwrap module. Implementation is for the most parts familiar from inspect.getdoc, though I used sring methods instead of the module 'string'. The module 'textwrap' and the function name 'dedent' were suggested on python-dev a while back (by MAL, IIRC). ---------------------------------------------------------------------- >Comment By: Ville Vainio (vvainio) Date: 2002-10-02 09:39 Message: Logged In: YES user_id=213488 Ok, I've added a patch for libtextwrap.tex. You might want to take a look at it for errors, this was my first time writing latex - I just followed the style used elsewhere in the file. Writing the test case might be handled by you in a more time-efficient manner, though I can also take a look at it once I get that linux partition going on my new home machine... ---------------------------------------------------------------------- Comment By: Ville Vainio (vvainio) Date: 2002-09-09 12:40 Message: Logged In: YES user_id=213488 Yes, I'll look into the patches for Doc and test - it just might take a short while (have to access anon cvs at work) - few weeks or so. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2002-09-04 16:43 Message: Logged In: YES user_id=14422 Looks fine to me. Can you provide a patch for Doc/lib/libtextwrap.tex as well? A patch to Lib/test/test_textwrap.py would be nice too, but I can take care of that if you prefer. (Any other diffs should just be uploaded to this patch report.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 21:57 Message: Logged In: YES user_id=6380 For Greg Ward. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=598163&group_id=5470 From noreply@sourceforge.net Wed Oct 2 13:23:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Oct 2002 05:23:50 -0700 Subject: [Patches] [ python-Patches-617312 ] debugger-controlled jumps (Psyco #3) Message-ID: Patches item #617312, was opened at 2002-10-01 23:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617312&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: debugger-controlled jumps (Psyco #3) Initial Comment: Psyco-friendly patch #3. Allows the C profile and trace functions (called upon function entry, line tracing, function exit, and exception) to alter some fields of the current PyFrameObject to influence the execution of the main loop. This is currently impossible because all the relevant fields are copied into local variables of eval_frame(), shadowing any subsequence change in the frame object. This is designed for what I plan to do with Psyco, but could also be used by advanced debuggers to allow the execution point to be modified by the user. Besides, the patch is just a matter of swapping a few lines in eval_frame(), introducing almost no extra complexity. In ceval.c:eval_frame(): The calls to call_trace(...PyTrace_CALL...) at the beginning of the code have been moved above the initialization of the local variables, allowing the trace functions to fiddle with the frame object before the main loop sees it. There is also a bug fix here: if the profile or trace functions raise an error at this point, eval_frame() used to quit without restoring tstate->frame and tstate->recursion_depth. [XXX should have been a bug report on its own] Finally, the call_trace() on SET_LINENO has been slightly modified to allow the trace function to move the execution point elsewhere. This is done by saving a few local variables are saved to and restored from the frame object around the call_trace(). The variables are the current instruction pointer (which was already saved in f->f_lasti, but is now restored from f->f_lasti too), and the current stack_pointer. Compatibility: f->f_stacktop normally remains NULL for the whole execution of the frame. This patch sets it to a non-NULL value for the duration of the call to the line-by-line trace function. I expect this not to cause any incompatibility because f->f_stacktop is not visible from Python code. I do not expect extension modules to rely on this detail. Note however that this has an influence on the GC, which only visits the stack if f->f_stacktop is set. Again, I assume this is not an issue -- it cannot even cause dead cycles to be detected earlier by the GC because as long as we are in the call_trace() call, we have a live reference to f. Performance: when tracing is on, SET_LINENO is now marginally slower. I guess this is not considered as an issue given the debugging nature of tracing. In Python 2.3, line tracing is currently *much* heavier and nobody seems to complain ;-) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-10-02 12:23 Message: Logged In: YES user_id=6656 What about the blockstack? Are you just relying on trace functions not moving f_lasti unwisely? Agree about the bug. Do you have a test case for it? Otherwise I'll cook one up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617312&group_id=5470 From noreply@sourceforge.net Wed Oct 2 14:14:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Oct 2002 06:14:54 -0700 Subject: [Patches] [ python-Patches-617312 ] debugger-controlled jumps (Psyco #3) Message-ID: Patches item #617312, was opened at 2002-10-01 23:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617312&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: debugger-controlled jumps (Psyco #3) Initial Comment: Psyco-friendly patch #3. Allows the C profile and trace functions (called upon function entry, line tracing, function exit, and exception) to alter some fields of the current PyFrameObject to influence the execution of the main loop. This is currently impossible because all the relevant fields are copied into local variables of eval_frame(), shadowing any subsequence change in the frame object. This is designed for what I plan to do with Psyco, but could also be used by advanced debuggers to allow the execution point to be modified by the user. Besides, the patch is just a matter of swapping a few lines in eval_frame(), introducing almost no extra complexity. In ceval.c:eval_frame(): The calls to call_trace(...PyTrace_CALL...) at the beginning of the code have been moved above the initialization of the local variables, allowing the trace functions to fiddle with the frame object before the main loop sees it. There is also a bug fix here: if the profile or trace functions raise an error at this point, eval_frame() used to quit without restoring tstate->frame and tstate->recursion_depth. [XXX should have been a bug report on its own] Finally, the call_trace() on SET_LINENO has been slightly modified to allow the trace function to move the execution point elsewhere. This is done by saving a few local variables are saved to and restored from the frame object around the call_trace(). The variables are the current instruction pointer (which was already saved in f->f_lasti, but is now restored from f->f_lasti too), and the current stack_pointer. Compatibility: f->f_stacktop normally remains NULL for the whole execution of the frame. This patch sets it to a non-NULL value for the duration of the call to the line-by-line trace function. I expect this not to cause any incompatibility because f->f_stacktop is not visible from Python code. I do not expect extension modules to rely on this detail. Note however that this has an influence on the GC, which only visits the stack if f->f_stacktop is set. Again, I assume this is not an issue -- it cannot even cause dead cycles to be detected earlier by the GC because as long as we are in the call_trace() call, we have a live reference to f. Performance: when tracing is on, SET_LINENO is now marginally slower. I guess this is not considered as an issue given the debugging nature of tracing. In Python 2.3, line tracing is currently *much* heavier and nobody seems to complain ;-) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-10-02 13:14 Message: Logged In: YES user_id=6656 Never mind, the bug offended me so much that I fixed it both on the trunk and the 22-maint branch. Python/ceval.c revisions 2.337 and 2.301.4.5 Lib/test/test_trace.py revisions 1.4 and 1.4.2.1 (probably a 2.1 bugix candidate, if any cares...) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-02 12:23 Message: Logged In: YES user_id=6656 What about the blockstack? Are you just relying on trace functions not moving f_lasti unwisely? Agree about the bug. Do you have a test case for it? Otherwise I'll cook one up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617312&group_id=5470 From noreply@sourceforge.net Wed Oct 2 21:33:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Oct 2002 13:33:28 -0700 Subject: [Patches] [ python-Patches-617312 ] debugger-controlled jumps (Psyco #3) Message-ID: Patches item #617312, was opened at 2002-10-01 23:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617312&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: debugger-controlled jumps (Psyco #3) Initial Comment: Psyco-friendly patch #3. Allows the C profile and trace functions (called upon function entry, line tracing, function exit, and exception) to alter some fields of the current PyFrameObject to influence the execution of the main loop. This is currently impossible because all the relevant fields are copied into local variables of eval_frame(), shadowing any subsequence change in the frame object. This is designed for what I plan to do with Psyco, but could also be used by advanced debuggers to allow the execution point to be modified by the user. Besides, the patch is just a matter of swapping a few lines in eval_frame(), introducing almost no extra complexity. In ceval.c:eval_frame(): The calls to call_trace(...PyTrace_CALL...) at the beginning of the code have been moved above the initialization of the local variables, allowing the trace functions to fiddle with the frame object before the main loop sees it. There is also a bug fix here: if the profile or trace functions raise an error at this point, eval_frame() used to quit without restoring tstate->frame and tstate->recursion_depth. [XXX should have been a bug report on its own] Finally, the call_trace() on SET_LINENO has been slightly modified to allow the trace function to move the execution point elsewhere. This is done by saving a few local variables are saved to and restored from the frame object around the call_trace(). The variables are the current instruction pointer (which was already saved in f->f_lasti, but is now restored from f->f_lasti too), and the current stack_pointer. Compatibility: f->f_stacktop normally remains NULL for the whole execution of the frame. This patch sets it to a non-NULL value for the duration of the call to the line-by-line trace function. I expect this not to cause any incompatibility because f->f_stacktop is not visible from Python code. I do not expect extension modules to rely on this detail. Note however that this has an influence on the GC, which only visits the stack if f->f_stacktop is set. Again, I assume this is not an issue -- it cannot even cause dead cycles to be detected earlier by the GC because as long as we are in the call_trace() call, we have a live reference to f. Performance: when tracing is on, SET_LINENO is now marginally slower. I guess this is not considered as an issue given the debugging nature of tracing. In Python 2.3, line tracing is currently *much* heavier and nobody seems to complain ;-) ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2002-10-02 20:33 Message: Logged In: YES user_id=4771 The trace function can change f_lasti if it knows what it does and if it accordingly changes all other fields too, like f_stacktop, f_blockstack and f_iblock. In fact, f_lasti and f_stacktop are the only fields of the frame objects that are currently cached in local variables (with the exception of what concerns the f_code object itself) so that this patch is enough to let the trace function actually move the execution point elsewhere. This would be quite useful in Psyco, if the rest of the function has been emulated and we then want the main loop to exit with the proper value: just move f_lasti just before the RETURN_VALUE opcode, clean up the stack and block stack, and push the already-computed result value where RETURN_VALUE will find it. Psyco could also execute just a part of the function and give it back to Python at some later position. A "clean hack". ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-02 13:14 Message: Logged In: YES user_id=6656 Never mind, the bug offended me so much that I fixed it both on the trunk and the 22-maint branch. Python/ceval.c revisions 2.337 and 2.301.4.5 Lib/test/test_trace.py revisions 1.4 and 1.4.2.1 (probably a 2.1 bugix candidate, if any cares...) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-02 12:23 Message: Logged In: YES user_id=6656 What about the blockstack? Are you just relying on trace functions not moving f_lasti unwisely? Agree about the bug. Do you have a test case for it? Otherwise I'll cook one up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617312&group_id=5470 From noreply@sourceforge.net Wed Oct 2 22:46:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Oct 2002 14:46:33 -0700 Subject: [Patches] [ python-Patches-617779 ] Rational Reference Implementation Message-ID: Patches item #617779, was opened at 2002-10-02 17:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617779&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christopher A. Craig (ccraig) Assigned to: Nobody/Anonymous (nobody) Summary: Rational Reference Implementation Initial Comment: This is a reference implementation of rational numbers (PEP239). It includes regression tests for rationals and changes to cPickle/pickle to support them. It has been tested on Solaris and Linux, but notably not Windows. This implementation does change the behaviour of future division to return a rational rather than a float. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617779&group_id=5470 From noreply@sourceforge.net Thu Oct 3 05:20:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Oct 2002 21:20:33 -0700 Subject: [Patches] [ python-Patches-617906 ] Build Error on Systems Without IPv6 Supp Message-ID: Patches item #617906, was opened at 2002-10-02 23:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617906&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Nobody/Anonymous (nobody) Summary: Build Error on Systems Without IPv6 Supp Initial Comment: The problem was discovered installing 2.2.1 from the src.rpm on a Redhat 6.2 system which does not have IPv6 support. The 17 Sept 02 revision of python-2.2.spec (2.2.1-2) defaults to building Python with the configure switch --enable-ipv6=yes. An AC_ARG_ENABLE macro in configure.in sets ENABLE_IPV6 if the config switch is set, without checking whether the system has the resources to build and run IPv6. This forces a compile with IPV6 support which fails on my system. Python then ends up without any socket support since .../lib-dynload/_socket.so is missing. Among other problems, this AC_ARG_ENABLE logic re-exposes Bug 454493. For clarity, the patch is provided in three stages, meant to be applied in sequence: 1. configure.in.patch1 supplies the minimum to move the AF_INET6 and RFC2553 tests out of the ACTION_IF_NOT_GIVEN section of the macro. A default of no IPv6 support is supplied. 2. configure.in.patch2 integrates the stack type and IPv6 library presence tests into the logic which sets ENABLE_IPV6. Trace messages are added to the test for IPv6 library presence. The logic is changed so that the build will default to IPv4 instead of exiting the configuration process if the IPv6 library is not found. IPv6 support is compiled only if the system passes all the tests. Finally, some comments in the stack type check are changed to allow them to appear in configure as well as configure.in. 3. configure.in.patch3 does whitespace normalization for this section of configure.in. This patch may solve the problem raised in Bug 553000; I experienced shell errors testing the various paths through the stack type check / library check until I quoted the shell variables in the library check. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617906&group_id=5470 From noreply@sourceforge.net Thu Oct 3 06:15:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Oct 2002 22:15:37 -0700 Subject: [Patches] [ python-Patches-594001 ] PEP 277: Unicode file name support Message-ID: Patches item #594001, was opened at 2002-08-12 21:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 Category: Windows Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Mark Hammond (mhammond) Summary: PEP 277: Unicode file name support Initial Comment: This patch is in an updated version of the patch [1] mentioned in the PEP. In addition to merging it with the CVS, it fixes a few formatting problems. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2002-10-03 15:15 Message: Logged In: YES user_id=14198 /cvsroot/python/python/dist/src/Include/pyerrors.h,v <-- pyerrors.h new revision: 2.61; previous revision: 2.60 /cvsroot/python/python/dist/src/Lib/test/test_unicode_file.py,v <-- test_unicode_file.py new revision: 1.6; previous revision: 1.5 /cvsroot/python/python/dist/src/Modules/posixmodule.c,v <-- posixmodule.c new revision: 2.261; previous revision: 2.260 /cvsroot/python/python/dist/src/Objects/fileobject.c,v <-- fileobject.c new revision: 2.169; previous revision: 2.168 /cvsroot/python/python/dist/src/PC/pyconfig.h,v <-- pyconfig.h new revision: 1.15; previous revision: 1.14 /cvsroot/python/python/dist/src/Python/errors.c,v <-- errors.c new revision: 2.72; previous revision: 2.71 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-02 03:41 Message: Logged In: YES user_id=21627 The patch passes the test suite on Solaris. I've also attached a documentation change, so I think the patch is ready now. Back to Mark for checkin. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-01 19:59 Message: Logged In: YES user_id=14198 The block: + if (!wpath1 || !wpath2) + return NULL; Should include Py_XDECREF calls for wpath1 and wpath2. Can't be bothered with a new patch just for this :) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-01 09:48 Message: Logged In: YES user_id=14198 Although SF implies otherwise, a bad filename in a submission appears to only prevent the file being uploaded - the rest of the comments etc come through. Hence my double-comments and strange status changes you can see. So, back to Martin as I don't think he is waiting on me for anything. Happy to check in if you like, but would like to see someone run a debug build of this through Linux first to see if any asserts fire - some asserts did indeed fire in the first version of this patch, and Linux may trigger others, or even the 2 that I added. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:54 Message: Logged In: YES user_id=14198 Sorry - not sure what I was thinking - obviously can't check in a patch known to crash the test suite! Attaching a new patch - fixes the problem I mentioned with test_unicode_files.py, fixes an error I introduced where the "WithFilename" error functions could be passed a NULL filename, and adding an assert to match the one I added previously. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:52 Message: Logged In: YES user_id=14198 Sorry - not sure what I was thinking - obviously can't check in a patch known to crash the test suite! Attaching a new patch. This fixes the crash in test_unicode_file I mentioned. It also fixes another error I introduced where PyErr_SetWithFilename functions can have NULL filenames. Also added an assert for symmetry with one I added before. Martin - back to me if you want me to check it in. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:21 Message: Logged In: YES user_id=14198 I missed the fact this was re-assigned to me - should I check my new patch in? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:20 Message: Logged In: YES user_id=14198 I get an exception running test_unicode_file.py - we end up with a MBCS encoded string passed to PyUnicode_FromEncodedObject(), that attempts to decode using the system default encoding rather than the file-system default. The error is a NULL pointer deref so should be obvious - unfortunately the fix requires a local reimplementation of PyUnicode_FromEncodedObject(), passing an explicit encoding for string objects. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 20:43 Message: Logged In: YES user_id=21627 Thanks for your comments, just shouting at me to correct all these problems would have been fine :-) In what case do you still get an exception? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:35 Message: Logged In: YES user_id=14198 Back to martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:34 Message: Logged In: YES user_id=14198 Back to Martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:33 Message: Logged In: YES user_id=14198 Uploading text file with my comments on the patch. Also uploading a new patch with these corrections and even better (?) error handling. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 11:03 Message: Logged In: YES user_id=14198 Will review this instant - sorry for the delay. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 16:24 Message: Logged In: YES user_id=21627 Mark, can you please indicate whether you will review this patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-26 05:43 Message: Logged In: YES user_id=31435 Sorry, Martin, bouncing back to Mark -- I really don't know anything about the Windows filename APIs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-23 01:31 Message: Logged In: YES user_id=21627 Tim, can you review this? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 22:06 Message: Logged In: YES user_id=21627 This is a new version: - wrapped all Windows wide API code with #ifdef Py_WIN_WIDE_FILENAMES - added test case Mark, can you please take a look at this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-12 23:38 Message: Logged In: YES user_id=6380 I'd make unicode_filenames() a macro that expands to 0 on platforms without this wart. I'd also test for wfunc!=NULL before calling unicode_filenames(). There's a lot of hairy code here. Are you sure that there are test cases in the test suite that exercise all of it? Aren't there some #ifdefs missing? posix_[12]str have code that's only relevant for Windows but isn't #ifdef'ed out like it is elsewhere. There should probably be a separate #define in pyport.h to test for this that's equivalent to defined(MS_WINDOWS) && !defined(Py_UNICODE_WIDE), so this can be uniformly tested to see whether this code is necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 From noreply@sourceforge.net Thu Oct 3 08:00:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 00:00:55 -0700 Subject: [Patches] [ python-Patches-594001 ] PEP 277: Unicode file name support Message-ID: Patches item #594001, was opened at 2002-08-12 21:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 Category: Windows Group: None >Status: Open Resolution: Fixed Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Mark Hammond (mhammond) Summary: PEP 277: Unicode file name support Initial Comment: This patch is in an updated version of the patch [1] mentioned in the PEP. In addition to merging it with the CVS, it fixes a few formatting problems. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2002-10-03 17:00 Message: Logged In: YES user_id=14198 Oops - I missed checking in Lib/test/test_pep277.py. With this file in place, the test suite fails for me: test_pep277 test test_pep277 produced unexpected output: ... However, I seem to recall that new tests do not need output files. Should I use the old technique of "regrtest -g ..." and check both the test and output file in, or is there something else I should be doing? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-03 15:15 Message: Logged In: YES user_id=14198 /cvsroot/python/python/dist/src/Include/pyerrors.h,v <-- pyerrors.h new revision: 2.61; previous revision: 2.60 /cvsroot/python/python/dist/src/Lib/test/test_unicode_file.py,v <-- test_unicode_file.py new revision: 1.6; previous revision: 1.5 /cvsroot/python/python/dist/src/Modules/posixmodule.c,v <-- posixmodule.c new revision: 2.261; previous revision: 2.260 /cvsroot/python/python/dist/src/Objects/fileobject.c,v <-- fileobject.c new revision: 2.169; previous revision: 2.168 /cvsroot/python/python/dist/src/PC/pyconfig.h,v <-- pyconfig.h new revision: 1.15; previous revision: 1.14 /cvsroot/python/python/dist/src/Python/errors.c,v <-- errors.c new revision: 2.72; previous revision: 2.71 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-02 03:41 Message: Logged In: YES user_id=21627 The patch passes the test suite on Solaris. I've also attached a documentation change, so I think the patch is ready now. Back to Mark for checkin. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-01 19:59 Message: Logged In: YES user_id=14198 The block: + if (!wpath1 || !wpath2) + return NULL; Should include Py_XDECREF calls for wpath1 and wpath2. Can't be bothered with a new patch just for this :) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-01 09:48 Message: Logged In: YES user_id=14198 Although SF implies otherwise, a bad filename in a submission appears to only prevent the file being uploaded - the rest of the comments etc come through. Hence my double-comments and strange status changes you can see. So, back to Martin as I don't think he is waiting on me for anything. Happy to check in if you like, but would like to see someone run a debug build of this through Linux first to see if any asserts fire - some asserts did indeed fire in the first version of this patch, and Linux may trigger others, or even the 2 that I added. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:54 Message: Logged In: YES user_id=14198 Sorry - not sure what I was thinking - obviously can't check in a patch known to crash the test suite! Attaching a new patch - fixes the problem I mentioned with test_unicode_files.py, fixes an error I introduced where the "WithFilename" error functions could be passed a NULL filename, and adding an assert to match the one I added previously. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:52 Message: Logged In: YES user_id=14198 Sorry - not sure what I was thinking - obviously can't check in a patch known to crash the test suite! Attaching a new patch. This fixes the crash in test_unicode_file I mentioned. It also fixes another error I introduced where PyErr_SetWithFilename functions can have NULL filenames. Also added an assert for symmetry with one I added before. Martin - back to me if you want me to check it in. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:21 Message: Logged In: YES user_id=14198 I missed the fact this was re-assigned to me - should I check my new patch in? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:20 Message: Logged In: YES user_id=14198 I get an exception running test_unicode_file.py - we end up with a MBCS encoded string passed to PyUnicode_FromEncodedObject(), that attempts to decode using the system default encoding rather than the file-system default. The error is a NULL pointer deref so should be obvious - unfortunately the fix requires a local reimplementation of PyUnicode_FromEncodedObject(), passing an explicit encoding for string objects. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 20:43 Message: Logged In: YES user_id=21627 Thanks for your comments, just shouting at me to correct all these problems would have been fine :-) In what case do you still get an exception? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:35 Message: Logged In: YES user_id=14198 Back to martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:34 Message: Logged In: YES user_id=14198 Back to Martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:33 Message: Logged In: YES user_id=14198 Uploading text file with my comments on the patch. Also uploading a new patch with these corrections and even better (?) error handling. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 11:03 Message: Logged In: YES user_id=14198 Will review this instant - sorry for the delay. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 16:24 Message: Logged In: YES user_id=21627 Mark, can you please indicate whether you will review this patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-26 05:43 Message: Logged In: YES user_id=31435 Sorry, Martin, bouncing back to Mark -- I really don't know anything about the Windows filename APIs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-23 01:31 Message: Logged In: YES user_id=21627 Tim, can you review this? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 22:06 Message: Logged In: YES user_id=21627 This is a new version: - wrapped all Windows wide API code with #ifdef Py_WIN_WIDE_FILENAMES - added test case Mark, can you please take a look at this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-12 23:38 Message: Logged In: YES user_id=6380 I'd make unicode_filenames() a macro that expands to 0 on platforms without this wart. I'd also test for wfunc!=NULL before calling unicode_filenames(). There's a lot of hairy code here. Are you sure that there are test cases in the test suite that exercise all of it? Aren't there some #ifdefs missing? posix_[12]str have code that's only relevant for Windows but isn't #ifdef'ed out like it is elsewhere. There should probably be a separate #define in pyport.h to test for this that's equivalent to defined(MS_WINDOWS) && !defined(Py_UNICODE_WIDE), so this can be uniformly tested to see whether this code is necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 From noreply@sourceforge.net Thu Oct 3 08:38:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 00:38:30 -0700 Subject: [Patches] [ python-Patches-614055 ] OpenVMS patches Message-ID: Patches item #614055, was opened at 2002-09-24 23:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614055&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Piéronne Jean-François (pieronne) Assigned to: Nobody/Anonymous (nobody) Summary: OpenVMS patches Initial Comment: The attach file contains the patches of the Core files necessary to build Python for OpenVMS. All the patches used conditional compilation test on __VMS, so I may not be disruptive for the initial code. 11 files have been updated: Python/exceptions.c Python/import.c Modules/getbuildinfo.c Modules/getpatch.c Modules/main.c Modules/posixmodule.c Modules/pwdmodule.c Modules/socketmodule.c Modules/stringobject.c Modules/_hotshot.c include/pyerrors.h Jean-François ---------------------------------------------------------------------- >Comment By: Piéronne Jean-François (pieronne) Date: 2002-10-03 09:38 Message: Logged In: YES user_id=414701 I have attach a new version(vms02.diff) using the latest CVS snapshot, I have also slightly update patch of main.c Thanks, Jean-François ---------------------------------------------------------------------- Comment By: Piéronne Jean-François (pieronne) Date: 2002-09-25 22:03 Message: Logged In: YES user_id=414701 Comment seem to be missing. VMSerror is used by many specifics module which I have not currently provide. I have correct the typo VMSerror --> VMSError formatting problem: Well, this is the formatting used by Uwe Zessin (and mostly generate by the editor LSE) who has done the initial port. I have not check/update his code because I did'nt know it is required, I have just found the "Style Guide for C Code". I have now update the code, only the VMS part ;-) Compute of the link time: Really necessary, sure it is not. But, IMHO, it is more useful to have the link time than the compile time of one source file. What is the problem? psxmod_gat_psxpath, psxmod_to_vms_action: You are right. During the cleaning process of the code of Uwe (I have remove some part), I have missed this optimisation and to remove the, then, unused routine psxmod_to_vms. Done, thanks. I have attach a new version: vms01.diff Tell me if you find other problem into this version. Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-25 15:02 Message: Logged In: YES user_id=21627 I have a number of comments and questions: - What is the purpose of VMSerror? It appears to be unused. Can you use just OSError instead? If not, it should be VMSError. - There are various formatting problems (indentation, spaces after function names). - Is it really necessary to compute the link time? - Why do you need psxmod_gat_psxpath? Copying into psxmod_gt_psxpath appears to do the same thing? - what is the purpose of psxmod_to_vms_action? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614055&group_id=5470 From noreply@sourceforge.net Thu Oct 3 09:08:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 01:08:58 -0700 Subject: [Patches] [ python-Patches-594001 ] PEP 277: Unicode file name support Message-ID: Patches item #594001, was opened at 2002-08-12 13:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 Category: Windows Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Mark Hammond (mhammond) Summary: PEP 277: Unicode file name support Initial Comment: This patch is in an updated version of the patch [1] mentioned in the PEP. In addition to merging it with the CVS, it fixes a few formatting problems. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 10:08 Message: Logged In: YES user_id=21627 Generating the output file with -g and committing it is the right thing to do. I noticed that a .sort call is missing parenthesis, which would need to be added. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-03 09:00 Message: Logged In: YES user_id=14198 Oops - I missed checking in Lib/test/test_pep277.py. With this file in place, the test suite fails for me: test_pep277 test test_pep277 produced unexpected output: ... However, I seem to recall that new tests do not need output files. Should I use the old technique of "regrtest -g ..." and check both the test and output file in, or is there something else I should be doing? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-03 07:15 Message: Logged In: YES user_id=14198 /cvsroot/python/python/dist/src/Include/pyerrors.h,v <-- pyerrors.h new revision: 2.61; previous revision: 2.60 /cvsroot/python/python/dist/src/Lib/test/test_unicode_file.py,v <-- test_unicode_file.py new revision: 1.6; previous revision: 1.5 /cvsroot/python/python/dist/src/Modules/posixmodule.c,v <-- posixmodule.c new revision: 2.261; previous revision: 2.260 /cvsroot/python/python/dist/src/Objects/fileobject.c,v <-- fileobject.c new revision: 2.169; previous revision: 2.168 /cvsroot/python/python/dist/src/PC/pyconfig.h,v <-- pyconfig.h new revision: 1.15; previous revision: 1.14 /cvsroot/python/python/dist/src/Python/errors.c,v <-- errors.c new revision: 2.72; previous revision: 2.71 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-01 19:41 Message: Logged In: YES user_id=21627 The patch passes the test suite on Solaris. I've also attached a documentation change, so I think the patch is ready now. Back to Mark for checkin. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-01 11:59 Message: Logged In: YES user_id=14198 The block: + if (!wpath1 || !wpath2) + return NULL; Should include Py_XDECREF calls for wpath1 and wpath2. Can't be bothered with a new patch just for this :) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-01 01:48 Message: Logged In: YES user_id=14198 Although SF implies otherwise, a bad filename in a submission appears to only prevent the file being uploaded - the rest of the comments etc come through. Hence my double-comments and strange status changes you can see. So, back to Martin as I don't think he is waiting on me for anything. Happy to check in if you like, but would like to see someone run a debug build of this through Linux first to see if any asserts fire - some asserts did indeed fire in the first version of this patch, and Linux may trigger others, or even the 2 that I added. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 14:54 Message: Logged In: YES user_id=14198 Sorry - not sure what I was thinking - obviously can't check in a patch known to crash the test suite! Attaching a new patch - fixes the problem I mentioned with test_unicode_files.py, fixes an error I introduced where the "WithFilename" error functions could be passed a NULL filename, and adding an assert to match the one I added previously. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 14:52 Message: Logged In: YES user_id=14198 Sorry - not sure what I was thinking - obviously can't check in a patch known to crash the test suite! Attaching a new patch. This fixes the crash in test_unicode_file I mentioned. It also fixes another error I introduced where PyErr_SetWithFilename functions can have NULL filenames. Also added an assert for symmetry with one I added before. Martin - back to me if you want me to check it in. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 14:21 Message: Logged In: YES user_id=14198 I missed the fact this was re-assigned to me - should I check my new patch in? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 14:20 Message: Logged In: YES user_id=14198 I get an exception running test_unicode_file.py - we end up with a MBCS encoded string passed to PyUnicode_FromEncodedObject(), that attempts to decode using the system default encoding rather than the file-system default. The error is a NULL pointer deref so should be obvious - unfortunately the fix requires a local reimplementation of PyUnicode_FromEncodedObject(), passing an explicit encoding for string objects. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 12:43 Message: Logged In: YES user_id=21627 Thanks for your comments, just shouting at me to correct all these problems would have been fine :-) In what case do you still get an exception? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 08:35 Message: Logged In: YES user_id=14198 Back to martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 08:34 Message: Logged In: YES user_id=14198 Back to Martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 08:33 Message: Logged In: YES user_id=14198 Uploading text file with my comments on the patch. Also uploading a new patch with these corrections and even better (?) error handling. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 03:03 Message: Logged In: YES user_id=14198 Will review this instant - sorry for the delay. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 08:24 Message: Logged In: YES user_id=21627 Mark, can you please indicate whether you will review this patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-25 21:43 Message: Logged In: YES user_id=31435 Sorry, Martin, bouncing back to Mark -- I really don't know anything about the Windows filename APIs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 17:31 Message: Logged In: YES user_id=21627 Tim, can you review this? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 14:06 Message: Logged In: YES user_id=21627 This is a new version: - wrapped all Windows wide API code with #ifdef Py_WIN_WIDE_FILENAMES - added test case Mark, can you please take a look at this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-12 15:38 Message: Logged In: YES user_id=6380 I'd make unicode_filenames() a macro that expands to 0 on platforms without this wart. I'd also test for wfunc!=NULL before calling unicode_filenames(). There's a lot of hairy code here. Are you sure that there are test cases in the test suite that exercise all of it? Aren't there some #ifdefs missing? posix_[12]str have code that's only relevant for Windows but isn't #ifdef'ed out like it is elsewhere. There should probably be a separate #define in pyport.h to test for this that's equivalent to defined(MS_WINDOWS) && !defined(Py_UNICODE_WIDE), so this can be uniformly tested to see whether this code is necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 From noreply@sourceforge.net Thu Oct 3 09:50:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 01:50:45 -0700 Subject: [Patches] [ python-Patches-617312 ] debugger-controlled jumps (Psyco #3) Message-ID: Patches item #617312, was opened at 2002-10-01 23:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617312&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) >Assigned to: Guido van Rossum (gvanrossum) Summary: debugger-controlled jumps (Psyco #3) Initial Comment: Psyco-friendly patch #3. Allows the C profile and trace functions (called upon function entry, line tracing, function exit, and exception) to alter some fields of the current PyFrameObject to influence the execution of the main loop. This is currently impossible because all the relevant fields are copied into local variables of eval_frame(), shadowing any subsequence change in the frame object. This is designed for what I plan to do with Psyco, but could also be used by advanced debuggers to allow the execution point to be modified by the user. Besides, the patch is just a matter of swapping a few lines in eval_frame(), introducing almost no extra complexity. In ceval.c:eval_frame(): The calls to call_trace(...PyTrace_CALL...) at the beginning of the code have been moved above the initialization of the local variables, allowing the trace functions to fiddle with the frame object before the main loop sees it. There is also a bug fix here: if the profile or trace functions raise an error at this point, eval_frame() used to quit without restoring tstate->frame and tstate->recursion_depth. [XXX should have been a bug report on its own] Finally, the call_trace() on SET_LINENO has been slightly modified to allow the trace function to move the execution point elsewhere. This is done by saving a few local variables are saved to and restored from the frame object around the call_trace(). The variables are the current instruction pointer (which was already saved in f->f_lasti, but is now restored from f->f_lasti too), and the current stack_pointer. Compatibility: f->f_stacktop normally remains NULL for the whole execution of the frame. This patch sets it to a non-NULL value for the duration of the call to the line-by-line trace function. I expect this not to cause any incompatibility because f->f_stacktop is not visible from Python code. I do not expect extension modules to rely on this detail. Note however that this has an influence on the GC, which only visits the stack if f->f_stacktop is set. Again, I assume this is not an issue -- it cannot even cause dead cycles to be detected earlier by the GC because as long as we are in the call_trace() call, we have a live reference to f. Performance: when tracing is on, SET_LINENO is now marginally slower. I guess this is not considered as an issue given the debugging nature of tracing. In Python 2.3, line tracing is currently *much* heavier and nobody seems to complain ;-) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-10-03 08:50 Message: Logged In: YES user_id=6656 Fair enough. Let's see what Guido thinks. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-02 20:33 Message: Logged In: YES user_id=4771 The trace function can change f_lasti if it knows what it does and if it accordingly changes all other fields too, like f_stacktop, f_blockstack and f_iblock. In fact, f_lasti and f_stacktop are the only fields of the frame objects that are currently cached in local variables (with the exception of what concerns the f_code object itself) so that this patch is enough to let the trace function actually move the execution point elsewhere. This would be quite useful in Psyco, if the rest of the function has been emulated and we then want the main loop to exit with the proper value: just move f_lasti just before the RETURN_VALUE opcode, clean up the stack and block stack, and push the already-computed result value where RETURN_VALUE will find it. Psyco could also execute just a part of the function and give it back to Python at some later position. A "clean hack". ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-02 13:14 Message: Logged In: YES user_id=6656 Never mind, the bug offended me so much that I fixed it both on the trunk and the 22-maint branch. Python/ceval.c revisions 2.337 and 2.301.4.5 Lib/test/test_trace.py revisions 1.4 and 1.4.2.1 (probably a 2.1 bugix candidate, if any cares...) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-02 12:23 Message: Logged In: YES user_id=6656 What about the blockstack? Are you just relying on trace functions not moving f_lasti unwisely? Agree about the bug. Do you have a test case for it? Otherwise I'll cook one up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617312&group_id=5470 From noreply@sourceforge.net Thu Oct 3 12:57:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 04:57:50 -0700 Subject: [Patches] [ python-Patches-614055 ] OpenVMS patches Message-ID: Patches item #614055, was opened at 2002-09-24 23:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614055&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Piéronne Jean-François (pieronne) Assigned to: Nobody/Anonymous (nobody) Summary: OpenVMS patches Initial Comment: The attach file contains the patches of the Core files necessary to build Python for OpenVMS. All the patches used conditional compilation test on __VMS, so I may not be disruptive for the initial code. 11 files have been updated: Python/exceptions.c Python/import.c Modules/getbuildinfo.c Modules/getpatch.c Modules/main.c Modules/posixmodule.c Modules/pwdmodule.c Modules/socketmodule.c Modules/stringobject.c Modules/_hotshot.c include/pyerrors.h Jean-François ---------------------------------------------------------------------- >Comment By: Piéronne Jean-François (pieronne) Date: 2002-10-03 13:57 Message: Logged In: YES user_id=414701 After testing using 20002-10-03_070000 some patches failed, This new version apply correctly. Jean-François ---------------------------------------------------------------------- Comment By: Piéronne Jean-François (pieronne) Date: 2002-10-03 09:38 Message: Logged In: YES user_id=414701 I have attach a new version(vms02.diff) using the latest CVS snapshot, I have also slightly update patch of main.c Thanks, Jean-François ---------------------------------------------------------------------- Comment By: Piéronne Jean-François (pieronne) Date: 2002-09-25 22:03 Message: Logged In: YES user_id=414701 Comment seem to be missing. VMSerror is used by many specifics module which I have not currently provide. I have correct the typo VMSerror --> VMSError formatting problem: Well, this is the formatting used by Uwe Zessin (and mostly generate by the editor LSE) who has done the initial port. I have not check/update his code because I did'nt know it is required, I have just found the "Style Guide for C Code". I have now update the code, only the VMS part ;-) Compute of the link time: Really necessary, sure it is not. But, IMHO, it is more useful to have the link time than the compile time of one source file. What is the problem? psxmod_gat_psxpath, psxmod_to_vms_action: You are right. During the cleaning process of the code of Uwe (I have remove some part), I have missed this optimisation and to remove the, then, unused routine psxmod_to_vms. Done, thanks. I have attach a new version: vms01.diff Tell me if you find other problem into this version. Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-25 15:02 Message: Logged In: YES user_id=21627 I have a number of comments and questions: - What is the purpose of VMSerror? It appears to be unused. Can you use just OSError instead? If not, it should be VMSError. - There are various formatting problems (indentation, spaces after function names). - Is it really necessary to compute the link time? - Why do you need psxmod_gat_psxpath? Copying into psxmod_gt_psxpath appears to do the same thing? - what is the purpose of psxmod_to_vms_action? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614055&group_id=5470 From noreply@sourceforge.net Thu Oct 3 16:53:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 08:53:05 -0700 Subject: [Patches] [ python-Patches-617906 ] Build Error on Systems Without IPv6 Supp Message-ID: Patches item #617906, was opened at 2002-10-03 06:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617906&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Nobody/Anonymous (nobody) Summary: Build Error on Systems Without IPv6 Supp Initial Comment: The problem was discovered installing 2.2.1 from the src.rpm on a Redhat 6.2 system which does not have IPv6 support. The 17 Sept 02 revision of python-2.2.spec (2.2.1-2) defaults to building Python with the configure switch --enable-ipv6=yes. An AC_ARG_ENABLE macro in configure.in sets ENABLE_IPV6 if the config switch is set, without checking whether the system has the resources to build and run IPv6. This forces a compile with IPV6 support which fails on my system. Python then ends up without any socket support since .../lib-dynload/_socket.so is missing. Among other problems, this AC_ARG_ENABLE logic re-exposes Bug 454493. For clarity, the patch is provided in three stages, meant to be applied in sequence: 1. configure.in.patch1 supplies the minimum to move the AF_INET6 and RFC2553 tests out of the ACTION_IF_NOT_GIVEN section of the macro. A default of no IPv6 support is supplied. 2. configure.in.patch2 integrates the stack type and IPv6 library presence tests into the logic which sets ENABLE_IPV6. Trace messages are added to the test for IPv6 library presence. The logic is changed so that the build will default to IPv4 instead of exiting the configuration process if the IPv6 library is not found. IPv6 support is compiled only if the system passes all the tests. Finally, some comments in the stack type check are changed to allow them to appear in configure as well as configure.in. 3. configure.in.patch3 does whitespace normalization for this section of configure.in. This patch may solve the problem raised in Bug 553000; I experienced shell errors testing the various paths through the stack type check / library check until I quoted the shell variables in the library check. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 17:53 Message: Logged In: YES user_id=21627 I fail to see the bug being fixed. An explicit --enable-ipv6 is meant to request explicitly request IPv6 support, overriding the automatic test that happens if you don't provide an option. So the right solution appears to be to change the spec file. I don't know where you got that spec file from, so I can't help here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617906&group_id=5470 From noreply@sourceforge.net Thu Oct 3 17:16:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 09:16:48 -0700 Subject: [Patches] [ python-Patches-618135 ] gzip.py and files > 2G Message-ID: Patches item #618135, was opened at 2002-10-03 18:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=618135&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Geert Jansen (geertj) Assigned to: Nobody/Anonymous (nobody) Summary: gzip.py and files > 2G Initial Comment: Problem: Currently, the gzip module is not able to work with files > 2G uncompressed. The source of the problem is that at the end of a .gz file, there is a trailer containing a 32 bit length field. This field is of course unable to represent a file length > 4G. Because of mixed type arithmetic in gzip.py, this limit is lowered to 2G. Testcase: python gzip.py # must be > 2G python gzip.py -d # error Proposed fix: Test the uncompressed data size modulo 4G. A patch implementing this fix is attached. This is also the solution that gzip itself uses. Two other remarks: I don't understand lines 22-23 of gzip.py: why is the test: "if value < 0" necessary when writing an unsigned int? The testing of the crc value in GzipFile._read_eof() is done modulo 4G. Is this necessary? crc32 is just read from the file as a normal int, and self.crc is from zlib.crc which always returns a regular int. Regards, Geert Jansen ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=618135&group_id=5470 From noreply@sourceforge.net Thu Oct 3 19:38:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 11:38:19 -0700 Subject: [Patches] [ python-Patches-617906 ] Build Error on Systems Without IPv6 Supp Message-ID: Patches item #617906, was opened at 2002-10-02 23:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617906&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Nobody/Anonymous (nobody) Summary: Build Error on Systems Without IPv6 Supp Initial Comment: The problem was discovered installing 2.2.1 from the src.rpm on a Redhat 6.2 system which does not have IPv6 support. The 17 Sept 02 revision of python-2.2.spec (2.2.1-2) defaults to building Python with the configure switch --enable-ipv6=yes. An AC_ARG_ENABLE macro in configure.in sets ENABLE_IPV6 if the config switch is set, without checking whether the system has the resources to build and run IPv6. This forces a compile with IPV6 support which fails on my system. Python then ends up without any socket support since .../lib-dynload/_socket.so is missing. Among other problems, this AC_ARG_ENABLE logic re-exposes Bug 454493. For clarity, the patch is provided in three stages, meant to be applied in sequence: 1. configure.in.patch1 supplies the minimum to move the AF_INET6 and RFC2553 tests out of the ACTION_IF_NOT_GIVEN section of the macro. A default of no IPv6 support is supplied. 2. configure.in.patch2 integrates the stack type and IPv6 library presence tests into the logic which sets ENABLE_IPV6. Trace messages are added to the test for IPv6 library presence. The logic is changed so that the build will default to IPv4 instead of exiting the configuration process if the IPv6 library is not found. IPv6 support is compiled only if the system passes all the tests. Finally, some comments in the stack type check are changed to allow them to appear in configure as well as configure.in. 3. configure.in.patch3 does whitespace normalization for this section of configure.in. This patch may solve the problem raised in Bug 553000; I experienced shell errors testing the various paths through the stack type check / library check until I quoted the shell variables in the library check. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2002-10-03 13:38 Message: Logged In: YES user_id=149084 Why have configure force a build which is going to fail, or lack runtime support? I guess I'm missing something here :-\ Is the main reason for the switch to provide a way to disable IPv6, or is there also a reason to override the AF_INET6 and RFC2553 tests? The patch ensures that those two tests are run even if the switch is explicitly set, informs the user what the problem is if for some reason the requested IPv6 support cannot be supplied, and provides a graceful fall-back to IPv4. Looking at this again, the current default if no switch is supplied is to attempt to configure IPv6. I chose no IPv6 support; I can provide an updated patch. The spec file is from the current 2.2.1 src.rpm http://www.python.org/2.2.1/rpms.html and Python Patch 611191. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 10:53 Message: Logged In: YES user_id=21627 I fail to see the bug being fixed. An explicit --enable-ipv6 is meant to request explicitly request IPv6 support, overriding the automatic test that happens if you don't provide an option. So the right solution appears to be to change the spec file. I don't know where you got that spec file from, so I can't help here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617906&group_id=5470 From noreply@sourceforge.net Thu Oct 3 20:12:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 12:12:56 -0700 Subject: [Patches] [ python-Patches-617906 ] Build Error on Systems Without IPv6 Supp Message-ID: Patches item #617906, was opened at 2002-10-03 06:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617906&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Nobody/Anonymous (nobody) Summary: Build Error on Systems Without IPv6 Supp Initial Comment: The problem was discovered installing 2.2.1 from the src.rpm on a Redhat 6.2 system which does not have IPv6 support. The 17 Sept 02 revision of python-2.2.spec (2.2.1-2) defaults to building Python with the configure switch --enable-ipv6=yes. An AC_ARG_ENABLE macro in configure.in sets ENABLE_IPV6 if the config switch is set, without checking whether the system has the resources to build and run IPv6. This forces a compile with IPV6 support which fails on my system. Python then ends up without any socket support since .../lib-dynload/_socket.so is missing. Among other problems, this AC_ARG_ENABLE logic re-exposes Bug 454493. For clarity, the patch is provided in three stages, meant to be applied in sequence: 1. configure.in.patch1 supplies the minimum to move the AF_INET6 and RFC2553 tests out of the ACTION_IF_NOT_GIVEN section of the macro. A default of no IPv6 support is supplied. 2. configure.in.patch2 integrates the stack type and IPv6 library presence tests into the logic which sets ENABLE_IPV6. Trace messages are added to the test for IPv6 library presence. The logic is changed so that the build will default to IPv4 instead of exiting the configuration process if the IPv6 library is not found. IPv6 support is compiled only if the system passes all the tests. Finally, some comments in the stack type check are changed to allow them to appear in configure as well as configure.in. 3. configure.in.patch3 does whitespace normalization for this section of configure.in. This patch may solve the problem raised in Bug 553000; I experienced shell errors testing the various paths through the stack type check / library check until I quoted the shell variables in the library check. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 21:12 Message: Logged In: YES user_id=21627 Can you please elaborate on how precisely the build fails on your system, and precisely what software you are using (operating system, C library)? It is the fallback to ignore the option that bothers me. The current configure is designed to stop the build process if a command line option has been provided, yet the requested feature cannot be activated. Errors should never pass silently. Unless explicitly silenced. If you don't want IPv6 support, build with --disable-ipv6. If you don't care, build with no option. If you absolutely must have IPv6, configure with --enable-ipv6. Seems logical to me. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-10-03 20:38 Message: Logged In: YES user_id=149084 Why have configure force a build which is going to fail, or lack runtime support? I guess I'm missing something here :-\ Is the main reason for the switch to provide a way to disable IPv6, or is there also a reason to override the AF_INET6 and RFC2553 tests? The patch ensures that those two tests are run even if the switch is explicitly set, informs the user what the problem is if for some reason the requested IPv6 support cannot be supplied, and provides a graceful fall-back to IPv4. Looking at this again, the current default if no switch is supplied is to attempt to configure IPv6. I chose no IPv6 support; I can provide an updated patch. The spec file is from the current 2.2.1 src.rpm http://www.python.org/2.2.1/rpms.html and Python Patch 611191. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 17:53 Message: Logged In: YES user_id=21627 I fail to see the bug being fixed. An explicit --enable-ipv6 is meant to request explicitly request IPv6 support, overriding the automatic test that happens if you don't provide an option. So the right solution appears to be to change the spec file. I don't know where you got that spec file from, so I can't help here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617906&group_id=5470 From noreply@sourceforge.net Thu Oct 3 21:58:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 13:58:20 -0700 Subject: [Patches] [ python-Patches-617906 ] Build Error on Systems Without IPv6 Supp Message-ID: Patches item #617906, was opened at 2002-10-02 23:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617906&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Nobody/Anonymous (nobody) Summary: Build Error on Systems Without IPv6 Supp Initial Comment: The problem was discovered installing 2.2.1 from the src.rpm on a Redhat 6.2 system which does not have IPv6 support. The 17 Sept 02 revision of python-2.2.spec (2.2.1-2) defaults to building Python with the configure switch --enable-ipv6=yes. An AC_ARG_ENABLE macro in configure.in sets ENABLE_IPV6 if the config switch is set, without checking whether the system has the resources to build and run IPv6. This forces a compile with IPV6 support which fails on my system. Python then ends up without any socket support since .../lib-dynload/_socket.so is missing. Among other problems, this AC_ARG_ENABLE logic re-exposes Bug 454493. For clarity, the patch is provided in three stages, meant to be applied in sequence: 1. configure.in.patch1 supplies the minimum to move the AF_INET6 and RFC2553 tests out of the ACTION_IF_NOT_GIVEN section of the macro. A default of no IPv6 support is supplied. 2. configure.in.patch2 integrates the stack type and IPv6 library presence tests into the logic which sets ENABLE_IPV6. Trace messages are added to the test for IPv6 library presence. The logic is changed so that the build will default to IPv4 instead of exiting the configuration process if the IPv6 library is not found. IPv6 support is compiled only if the system passes all the tests. Finally, some comments in the stack type check are changed to allow them to appear in configure as well as configure.in. 3. configure.in.patch3 does whitespace normalization for this section of configure.in. This patch may solve the problem raised in Bug 553000; I experienced shell errors testing the various paths through the stack type check / library check until I quoted the shell variables in the library check. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2002-10-03 15:58 Message: Logged In: YES user_id=149084 > Can you please elaborate on how precisely the build > fails on your system, and precisely what software you > are using (operating system, C library)? Linux float.attbi.com 2.2.5-15 RH 6.2(+) glibc-2.1.3-23 glibc-devel-2.1.3-23 [kbk@float ~]$ rpm -qi python2 Name : python2 Relocations: /usr Version : 2.2.1 Vendor: (none) Release : 2 Build Date: Sat Sep 28 01:11:35 2002 Install date: Sat Sep 28 01:41:58 2002 Build Host: float.attbi.com Group : Development/Languages Source RPM: python2-2.2.1-2.src.rpm Excerpt from the build log: ================== checking for usconfig in -lmpc... no checking for thr_create in -lthread... no checking if --enable-ipv6 is specified... yes checking ipv6 stack type... linux-glibc checking for --with-cycle-gc... yes checking for --with-pymalloc... no [...] building '_socket' extension /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c: In function `make\sockaddr': /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c:733: structure has\ no member named `sin6_scope_id' /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c: In function `gets\ockaddrarg': /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c:846: structure has\ no member named `sin6_scope_id' /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c: In function `PySo\cket_getnameinfo': /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c:2598: structure ha\s no member named `sin6_scope_id' gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DUSE_SSL=1 -I. -I/usr/loca\l/src/rpm/BUILD/Python-2.2.1/./Include -I/usr/local/include -IInclude/ -c /usr/\local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c -o build/temp.linux-i68\6-2.2/socketmodule.o WARNING: building of extension "_socket" failed: command 'gcc' failed with exit\ status 1 =================== ** Because the .spec sets the --enable-ipv6 the AF_INET6 and RFC2553 tests were skipped. _socket.so was not created, but the build continued with no socket support at all. ** If I run ./configure --enable-ipv6=no _socket.so is built as follows: ====================== building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DUSE_SSL=1 -I. -I/usr/loca\l/src/rpm/BUILD/Python-2.2.1/./Include -I/usr/local/include -IInclude/ -c /usr/\local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c -o build/temp.linux-i68\6-2.2/socketmodule.o gcc -shared build/temp.linux-i686-2.2/socketmodule.o -L/usr/local/lib -lssl -lc\rypto -o build/lib.linux-i686-2.2/_socket.so ========================== ** If I run ./configure with no switch, I get the same. The AF_INET6 test fails (silently) and I get IPv4. > It is the fallback to ignore the option that bothers > me. The current configure is designed to stop the > build process if a command line option has been > provided, yet the requested feature cannot be > activated. I see what you're saying. OTOH, it appears that the IPv6 configuration is the only part of configure that will terminate the configure script if a test fails. (buggygetaddrinfo also exits on failure). If this is really desired, one could insert an exit in the AC_MSG_CHECKING(if IPv6 can be configured) code if ipv6=0 (one of the four tests failed) _and_ the switch was enabled. > Errors should never pass silently. Unless explicitly > silenced. I'm not sure the user knows that he is silencing any errors. The configure --help merely states that --enable-ipv6=yes will enable IPv6, not that any tests will be bypassed. > If you don't want IPv6 support, build with > --disable-ipv6. yes > If you don't care, build with no option. yes > If you absolutely must have IPv6, configure with > --enable-ipv6. except that you can't have it if you don't have the libraries and runtime support. (Unless there is something going on here that I don't know about :) Sorry this is so long but you asked :-) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 14:12 Message: Logged In: YES user_id=21627 Can you please elaborate on how precisely the build fails on your system, and precisely what software you are using (operating system, C library)? It is the fallback to ignore the option that bothers me. The current configure is designed to stop the build process if a command line option has been provided, yet the requested feature cannot be activated. Errors should never pass silently. Unless explicitly silenced. If you don't want IPv6 support, build with --disable-ipv6. If you don't care, build with no option. If you absolutely must have IPv6, configure with --enable-ipv6. Seems logical to me. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-10-03 13:38 Message: Logged In: YES user_id=149084 Why have configure force a build which is going to fail, or lack runtime support? I guess I'm missing something here :-\ Is the main reason for the switch to provide a way to disable IPv6, or is there also a reason to override the AF_INET6 and RFC2553 tests? The patch ensures that those two tests are run even if the switch is explicitly set, informs the user what the problem is if for some reason the requested IPv6 support cannot be supplied, and provides a graceful fall-back to IPv4. Looking at this again, the current default if no switch is supplied is to attempt to configure IPv6. I chose no IPv6 support; I can provide an updated patch. The spec file is from the current 2.2.1 src.rpm http://www.python.org/2.2.1/rpms.html and Python Patch 611191. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 10:53 Message: Logged In: YES user_id=21627 I fail to see the bug being fixed. An explicit --enable-ipv6 is meant to request explicitly request IPv6 support, overriding the automatic test that happens if you don't provide an option. So the right solution appears to be to change the spec file. I don't know where you got that spec file from, so I can't help here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617906&group_id=5470 From noreply@sourceforge.net Fri Oct 4 00:15:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 16:15:47 -0700 Subject: [Patches] [ python-Patches-594001 ] PEP 277: Unicode file name support Message-ID: Patches item #594001, was opened at 2002-08-12 21:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 Category: Windows Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Mark Hammond (mhammond) Summary: PEP 277: Unicode file name support Initial Comment: This patch is in an updated version of the patch [1] mentioned in the PEP. In addition to merging it with the CVS, it fixes a few formatting problems. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2002-10-04 09:15 Message: Logged In: YES user_id=14198 /cvsroot/python/python/dist/src/Lib/test/test_pep277.py,v <-- test_pep277.py initial revision: 1.1 RCS file: /cvsroot/python/python/dist/src/Lib/test/output/test_pep277,v /cvsroot/python/python/dist/src/Lib/test/output/test_pep277,v <-- test_pep277 initial revision: 1.1 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 18:08 Message: Logged In: YES user_id=21627 Generating the output file with -g and committing it is the right thing to do. I noticed that a .sort call is missing parenthesis, which would need to be added. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-03 17:00 Message: Logged In: YES user_id=14198 Oops - I missed checking in Lib/test/test_pep277.py. With this file in place, the test suite fails for me: test_pep277 test test_pep277 produced unexpected output: ... However, I seem to recall that new tests do not need output files. Should I use the old technique of "regrtest -g ..." and check both the test and output file in, or is there something else I should be doing? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-03 15:15 Message: Logged In: YES user_id=14198 /cvsroot/python/python/dist/src/Include/pyerrors.h,v <-- pyerrors.h new revision: 2.61; previous revision: 2.60 /cvsroot/python/python/dist/src/Lib/test/test_unicode_file.py,v <-- test_unicode_file.py new revision: 1.6; previous revision: 1.5 /cvsroot/python/python/dist/src/Modules/posixmodule.c,v <-- posixmodule.c new revision: 2.261; previous revision: 2.260 /cvsroot/python/python/dist/src/Objects/fileobject.c,v <-- fileobject.c new revision: 2.169; previous revision: 2.168 /cvsroot/python/python/dist/src/PC/pyconfig.h,v <-- pyconfig.h new revision: 1.15; previous revision: 1.14 /cvsroot/python/python/dist/src/Python/errors.c,v <-- errors.c new revision: 2.72; previous revision: 2.71 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-02 03:41 Message: Logged In: YES user_id=21627 The patch passes the test suite on Solaris. I've also attached a documentation change, so I think the patch is ready now. Back to Mark for checkin. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-01 19:59 Message: Logged In: YES user_id=14198 The block: + if (!wpath1 || !wpath2) + return NULL; Should include Py_XDECREF calls for wpath1 and wpath2. Can't be bothered with a new patch just for this :) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-01 09:48 Message: Logged In: YES user_id=14198 Although SF implies otherwise, a bad filename in a submission appears to only prevent the file being uploaded - the rest of the comments etc come through. Hence my double-comments and strange status changes you can see. So, back to Martin as I don't think he is waiting on me for anything. Happy to check in if you like, but would like to see someone run a debug build of this through Linux first to see if any asserts fire - some asserts did indeed fire in the first version of this patch, and Linux may trigger others, or even the 2 that I added. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:54 Message: Logged In: YES user_id=14198 Sorry - not sure what I was thinking - obviously can't check in a patch known to crash the test suite! Attaching a new patch - fixes the problem I mentioned with test_unicode_files.py, fixes an error I introduced where the "WithFilename" error functions could be passed a NULL filename, and adding an assert to match the one I added previously. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:52 Message: Logged In: YES user_id=14198 Sorry - not sure what I was thinking - obviously can't check in a patch known to crash the test suite! Attaching a new patch. This fixes the crash in test_unicode_file I mentioned. It also fixes another error I introduced where PyErr_SetWithFilename functions can have NULL filenames. Also added an assert for symmetry with one I added before. Martin - back to me if you want me to check it in. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:21 Message: Logged In: YES user_id=14198 I missed the fact this was re-assigned to me - should I check my new patch in? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:20 Message: Logged In: YES user_id=14198 I get an exception running test_unicode_file.py - we end up with a MBCS encoded string passed to PyUnicode_FromEncodedObject(), that attempts to decode using the system default encoding rather than the file-system default. The error is a NULL pointer deref so should be obvious - unfortunately the fix requires a local reimplementation of PyUnicode_FromEncodedObject(), passing an explicit encoding for string objects. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 20:43 Message: Logged In: YES user_id=21627 Thanks for your comments, just shouting at me to correct all these problems would have been fine :-) In what case do you still get an exception? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:35 Message: Logged In: YES user_id=14198 Back to martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:34 Message: Logged In: YES user_id=14198 Back to Martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:33 Message: Logged In: YES user_id=14198 Uploading text file with my comments on the patch. Also uploading a new patch with these corrections and even better (?) error handling. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 11:03 Message: Logged In: YES user_id=14198 Will review this instant - sorry for the delay. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 16:24 Message: Logged In: YES user_id=21627 Mark, can you please indicate whether you will review this patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-26 05:43 Message: Logged In: YES user_id=31435 Sorry, Martin, bouncing back to Mark -- I really don't know anything about the Windows filename APIs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-23 01:31 Message: Logged In: YES user_id=21627 Tim, can you review this? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 22:06 Message: Logged In: YES user_id=21627 This is a new version: - wrapped all Windows wide API code with #ifdef Py_WIN_WIDE_FILENAMES - added test case Mark, can you please take a look at this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-12 23:38 Message: Logged In: YES user_id=6380 I'd make unicode_filenames() a macro that expands to 0 on platforms without this wart. I'd also test for wfunc!=NULL before calling unicode_filenames(). There's a lot of hairy code here. Are you sure that there are test cases in the test suite that exercise all of it? Aren't there some #ifdefs missing? posix_[12]str have code that's only relevant for Windows but isn't #ifdef'ed out like it is elsewhere. There should probably be a separate #define in pyport.h to test for this that's equivalent to defined(MS_WINDOWS) && !defined(Py_UNICODE_WIDE), so this can be uniformly tested to see whether this code is necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 From noreply@sourceforge.net Fri Oct 4 00:43:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 16:43:28 -0700 Subject: [Patches] [ python-Patches-594001 ] PEP 277: Unicode file name support Message-ID: Patches item #594001, was opened at 2002-08-12 07:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 Category: Windows Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Mark Hammond (mhammond) Summary: PEP 277: Unicode file name support Initial Comment: This patch is in an updated version of the patch [1] mentioned in the PEP. In addition to merging it with the CVS, it fixes a few formatting problems. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-03 19:43 Message: Logged In: YES user_id=33168 Mark, I had a bunch of code review notes I sent to python-checkins. I'm not sure you saw them, since my mail to you @ users.sf.net apparently doesn't want to go out. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-03 19:15 Message: Logged In: YES user_id=14198 /cvsroot/python/python/dist/src/Lib/test/test_pep277.py,v <-- test_pep277.py initial revision: 1.1 RCS file: /cvsroot/python/python/dist/src/Lib/test/output/test_pep277,v /cvsroot/python/python/dist/src/Lib/test/output/test_pep277,v <-- test_pep277 initial revision: 1.1 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 04:08 Message: Logged In: YES user_id=21627 Generating the output file with -g and committing it is the right thing to do. I noticed that a .sort call is missing parenthesis, which would need to be added. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-03 03:00 Message: Logged In: YES user_id=14198 Oops - I missed checking in Lib/test/test_pep277.py. With this file in place, the test suite fails for me: test_pep277 test test_pep277 produced unexpected output: ... However, I seem to recall that new tests do not need output files. Should I use the old technique of "regrtest -g ..." and check both the test and output file in, or is there something else I should be doing? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-03 01:15 Message: Logged In: YES user_id=14198 /cvsroot/python/python/dist/src/Include/pyerrors.h,v <-- pyerrors.h new revision: 2.61; previous revision: 2.60 /cvsroot/python/python/dist/src/Lib/test/test_unicode_file.py,v <-- test_unicode_file.py new revision: 1.6; previous revision: 1.5 /cvsroot/python/python/dist/src/Modules/posixmodule.c,v <-- posixmodule.c new revision: 2.261; previous revision: 2.260 /cvsroot/python/python/dist/src/Objects/fileobject.c,v <-- fileobject.c new revision: 2.169; previous revision: 2.168 /cvsroot/python/python/dist/src/PC/pyconfig.h,v <-- pyconfig.h new revision: 1.15; previous revision: 1.14 /cvsroot/python/python/dist/src/Python/errors.c,v <-- errors.c new revision: 2.72; previous revision: 2.71 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-01 13:41 Message: Logged In: YES user_id=21627 The patch passes the test suite on Solaris. I've also attached a documentation change, so I think the patch is ready now. Back to Mark for checkin. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-01 05:59 Message: Logged In: YES user_id=14198 The block: + if (!wpath1 || !wpath2) + return NULL; Should include Py_XDECREF calls for wpath1 and wpath2. Can't be bothered with a new patch just for this :) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 19:48 Message: Logged In: YES user_id=14198 Although SF implies otherwise, a bad filename in a submission appears to only prevent the file being uploaded - the rest of the comments etc come through. Hence my double-comments and strange status changes you can see. So, back to Martin as I don't think he is waiting on me for anything. Happy to check in if you like, but would like to see someone run a debug build of this through Linux first to see if any asserts fire - some asserts did indeed fire in the first version of this patch, and Linux may trigger others, or even the 2 that I added. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 08:54 Message: Logged In: YES user_id=14198 Sorry - not sure what I was thinking - obviously can't check in a patch known to crash the test suite! Attaching a new patch - fixes the problem I mentioned with test_unicode_files.py, fixes an error I introduced where the "WithFilename" error functions could be passed a NULL filename, and adding an assert to match the one I added previously. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 08:52 Message: Logged In: YES user_id=14198 Sorry - not sure what I was thinking - obviously can't check in a patch known to crash the test suite! Attaching a new patch. This fixes the crash in test_unicode_file I mentioned. It also fixes another error I introduced where PyErr_SetWithFilename functions can have NULL filenames. Also added an assert for symmetry with one I added before. Martin - back to me if you want me to check it in. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 08:21 Message: Logged In: YES user_id=14198 I missed the fact this was re-assigned to me - should I check my new patch in? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 08:20 Message: Logged In: YES user_id=14198 I get an exception running test_unicode_file.py - we end up with a MBCS encoded string passed to PyUnicode_FromEncodedObject(), that attempts to decode using the system default encoding rather than the file-system default. The error is a NULL pointer deref so should be obvious - unfortunately the fix requires a local reimplementation of PyUnicode_FromEncodedObject(), passing an explicit encoding for string objects. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 06:43 Message: Logged In: YES user_id=21627 Thanks for your comments, just shouting at me to correct all these problems would have been fine :-) In what case do you still get an exception? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 02:35 Message: Logged In: YES user_id=14198 Back to martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 02:34 Message: Logged In: YES user_id=14198 Back to Martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 02:33 Message: Logged In: YES user_id=14198 Uploading text file with my comments on the patch. Also uploading a new patch with these corrections and even better (?) error handling. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-29 21:03 Message: Logged In: YES user_id=14198 Will review this instant - sorry for the delay. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 02:24 Message: Logged In: YES user_id=21627 Mark, can you please indicate whether you will review this patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-25 15:43 Message: Logged In: YES user_id=31435 Sorry, Martin, bouncing back to Mark -- I really don't know anything about the Windows filename APIs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 11:31 Message: Logged In: YES user_id=21627 Tim, can you review this? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 08:06 Message: Logged In: YES user_id=21627 This is a new version: - wrapped all Windows wide API code with #ifdef Py_WIN_WIDE_FILENAMES - added test case Mark, can you please take a look at this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-12 09:38 Message: Logged In: YES user_id=6380 I'd make unicode_filenames() a macro that expands to 0 on platforms without this wart. I'd also test for wfunc!=NULL before calling unicode_filenames(). There's a lot of hairy code here. Are you sure that there are test cases in the test suite that exercise all of it? Aren't there some #ifdefs missing? posix_[12]str have code that's only relevant for Windows but isn't #ifdef'ed out like it is elsewhere. There should probably be a separate #define in pyport.h to test for this that's equivalent to defined(MS_WINDOWS) && !defined(Py_UNICODE_WIDE), so this can be uniformly tested to see whether this code is necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 From noreply@sourceforge.net Fri Oct 4 00:53:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 16:53:10 -0700 Subject: [Patches] [ python-Patches-594001 ] PEP 277: Unicode file name support Message-ID: Patches item #594001, was opened at 2002-08-12 21:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 Category: Windows Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Mark Hammond (mhammond) Summary: PEP 277: Unicode file name support Initial Comment: This patch is in an updated version of the patch [1] mentioned in the PEP. In addition to merging it with the CVS, it fixes a few formatting problems. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2002-10-04 09:53 Message: Logged In: YES user_id=14198 I will try and fix my sf.net mail - in tne meantime Neal, if you could forward them to my skippinet address I will address them. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-04 09:43 Message: Logged In: YES user_id=33168 Mark, I had a bunch of code review notes I sent to python-checkins. I'm not sure you saw them, since my mail to you @ users.sf.net apparently doesn't want to go out. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-04 09:15 Message: Logged In: YES user_id=14198 /cvsroot/python/python/dist/src/Lib/test/test_pep277.py,v <-- test_pep277.py initial revision: 1.1 RCS file: /cvsroot/python/python/dist/src/Lib/test/output/test_pep277,v /cvsroot/python/python/dist/src/Lib/test/output/test_pep277,v <-- test_pep277 initial revision: 1.1 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 18:08 Message: Logged In: YES user_id=21627 Generating the output file with -g and committing it is the right thing to do. I noticed that a .sort call is missing parenthesis, which would need to be added. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-03 17:00 Message: Logged In: YES user_id=14198 Oops - I missed checking in Lib/test/test_pep277.py. With this file in place, the test suite fails for me: test_pep277 test test_pep277 produced unexpected output: ... However, I seem to recall that new tests do not need output files. Should I use the old technique of "regrtest -g ..." and check both the test and output file in, or is there something else I should be doing? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-03 15:15 Message: Logged In: YES user_id=14198 /cvsroot/python/python/dist/src/Include/pyerrors.h,v <-- pyerrors.h new revision: 2.61; previous revision: 2.60 /cvsroot/python/python/dist/src/Lib/test/test_unicode_file.py,v <-- test_unicode_file.py new revision: 1.6; previous revision: 1.5 /cvsroot/python/python/dist/src/Modules/posixmodule.c,v <-- posixmodule.c new revision: 2.261; previous revision: 2.260 /cvsroot/python/python/dist/src/Objects/fileobject.c,v <-- fileobject.c new revision: 2.169; previous revision: 2.168 /cvsroot/python/python/dist/src/PC/pyconfig.h,v <-- pyconfig.h new revision: 1.15; previous revision: 1.14 /cvsroot/python/python/dist/src/Python/errors.c,v <-- errors.c new revision: 2.72; previous revision: 2.71 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-02 03:41 Message: Logged In: YES user_id=21627 The patch passes the test suite on Solaris. I've also attached a documentation change, so I think the patch is ready now. Back to Mark for checkin. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-01 19:59 Message: Logged In: YES user_id=14198 The block: + if (!wpath1 || !wpath2) + return NULL; Should include Py_XDECREF calls for wpath1 and wpath2. Can't be bothered with a new patch just for this :) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-01 09:48 Message: Logged In: YES user_id=14198 Although SF implies otherwise, a bad filename in a submission appears to only prevent the file being uploaded - the rest of the comments etc come through. Hence my double-comments and strange status changes you can see. So, back to Martin as I don't think he is waiting on me for anything. Happy to check in if you like, but would like to see someone run a debug build of this through Linux first to see if any asserts fire - some asserts did indeed fire in the first version of this patch, and Linux may trigger others, or even the 2 that I added. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:54 Message: Logged In: YES user_id=14198 Sorry - not sure what I was thinking - obviously can't check in a patch known to crash the test suite! Attaching a new patch - fixes the problem I mentioned with test_unicode_files.py, fixes an error I introduced where the "WithFilename" error functions could be passed a NULL filename, and adding an assert to match the one I added previously. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:52 Message: Logged In: YES user_id=14198 Sorry - not sure what I was thinking - obviously can't check in a patch known to crash the test suite! Attaching a new patch. This fixes the crash in test_unicode_file I mentioned. It also fixes another error I introduced where PyErr_SetWithFilename functions can have NULL filenames. Also added an assert for symmetry with one I added before. Martin - back to me if you want me to check it in. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:21 Message: Logged In: YES user_id=14198 I missed the fact this was re-assigned to me - should I check my new patch in? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:20 Message: Logged In: YES user_id=14198 I get an exception running test_unicode_file.py - we end up with a MBCS encoded string passed to PyUnicode_FromEncodedObject(), that attempts to decode using the system default encoding rather than the file-system default. The error is a NULL pointer deref so should be obvious - unfortunately the fix requires a local reimplementation of PyUnicode_FromEncodedObject(), passing an explicit encoding for string objects. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 20:43 Message: Logged In: YES user_id=21627 Thanks for your comments, just shouting at me to correct all these problems would have been fine :-) In what case do you still get an exception? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:35 Message: Logged In: YES user_id=14198 Back to martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:34 Message: Logged In: YES user_id=14198 Back to Martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:33 Message: Logged In: YES user_id=14198 Uploading text file with my comments on the patch. Also uploading a new patch with these corrections and even better (?) error handling. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 11:03 Message: Logged In: YES user_id=14198 Will review this instant - sorry for the delay. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 16:24 Message: Logged In: YES user_id=21627 Mark, can you please indicate whether you will review this patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-26 05:43 Message: Logged In: YES user_id=31435 Sorry, Martin, bouncing back to Mark -- I really don't know anything about the Windows filename APIs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-23 01:31 Message: Logged In: YES user_id=21627 Tim, can you review this? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 22:06 Message: Logged In: YES user_id=21627 This is a new version: - wrapped all Windows wide API code with #ifdef Py_WIN_WIDE_FILENAMES - added test case Mark, can you please take a look at this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-12 23:38 Message: Logged In: YES user_id=6380 I'd make unicode_filenames() a macro that expands to 0 on platforms without this wart. I'd also test for wfunc!=NULL before calling unicode_filenames(). There's a lot of hairy code here. Are you sure that there are test cases in the test suite that exercise all of it? Aren't there some #ifdefs missing? posix_[12]str have code that's only relevant for Windows but isn't #ifdef'ed out like it is elsewhere. There should probably be a separate #define in pyport.h to test for this that's equivalent to defined(MS_WINDOWS) && !defined(Py_UNICODE_WIDE), so this can be uniformly tested to see whether this code is necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 From noreply@sourceforge.net Fri Oct 4 03:06:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 19:06:48 -0700 Subject: [Patches] [ python-Patches-618347 ] pthread header fix for Solaris 2.6 Message-ID: Patches item #618347, was opened at 2002-10-03 21:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=618347&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Bauer (jeffbauer) Assigned to: Nobody/Anonymous (nobody) Summary: pthread header fix for Solaris 2.6 Initial Comment: This is a fix for bug item #617878. It's a bug in the pthread header of Solaris 2.6. According to Martin v. Löwis this problem only occurs in 2.6. Later versions don't use destructor in the header file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=618347&group_id=5470 From noreply@sourceforge.net Fri Oct 4 03:08:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 19:08:10 -0700 Subject: [Patches] [ python-Patches-618347 ] pthread header fix for Solaris 2.6 Message-ID: Patches item #618347, was opened at 2002-10-03 21:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=618347&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Bauer (jeffbauer) >Assigned to: Martin v. Löwis (loewis) Summary: pthread header fix for Solaris 2.6 Initial Comment: This is a fix for bug item #617878. It's a bug in the pthread header of Solaris 2.6. According to Martin v. Löwis this problem only occurs in 2.6. Later versions don't use destructor in the header file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=618347&group_id=5470 From noreply@sourceforge.net Fri Oct 4 03:22:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 19:22:45 -0700 Subject: [Patches] [ python-Patches-618347 ] pthread header fix for Solaris 2.6 Message-ID: Patches item #618347, was opened at 2002-10-03 21:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=618347&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Bauer (jeffbauer) Assigned to: Martin v. Löwis (loewis) Summary: pthread header fix for Solaris 2.6 Initial Comment: This is a fix for bug item #617878. It's a bug in the pthread header of Solaris 2.6. According to Martin v. Löwis this problem only occurs in 2.6. Later versions don't use destructor in the header file. ---------------------------------------------------------------------- >Comment By: Jeff Bauer (jeffbauer) Date: 2002-10-03 21:22 Message: Logged In: YES user_id=458828 Argh! Patch manager won't allow me to delete/replace the bad diff file. Ignore the first one with the timestamp of 2002-10-03 21:06 and use the second file instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=618347&group_id=5470 From noreply@sourceforge.net Fri Oct 4 07:39:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 23:39:01 -0700 Subject: [Patches] [ python-Patches-617906 ] Build Error on Systems Without IPv6 Supp Message-ID: Patches item #617906, was opened at 2002-10-03 06:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617906&group_id=5470 Category: Build Group: Python 2.2.x >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Nobody/Anonymous (nobody) Summary: Build Error on Systems Without IPv6 Supp Initial Comment: The problem was discovered installing 2.2.1 from the src.rpm on a Redhat 6.2 system which does not have IPv6 support. The 17 Sept 02 revision of python-2.2.spec (2.2.1-2) defaults to building Python with the configure switch --enable-ipv6=yes. An AC_ARG_ENABLE macro in configure.in sets ENABLE_IPV6 if the config switch is set, without checking whether the system has the resources to build and run IPv6. This forces a compile with IPV6 support which fails on my system. Python then ends up without any socket support since .../lib-dynload/_socket.so is missing. Among other problems, this AC_ARG_ENABLE logic re-exposes Bug 454493. For clarity, the patch is provided in three stages, meant to be applied in sequence: 1. configure.in.patch1 supplies the minimum to move the AF_INET6 and RFC2553 tests out of the ACTION_IF_NOT_GIVEN section of the macro. A default of no IPv6 support is supplied. 2. configure.in.patch2 integrates the stack type and IPv6 library presence tests into the logic which sets ENABLE_IPV6. Trace messages are added to the test for IPv6 library presence. The logic is changed so that the build will default to IPv4 instead of exiting the configuration process if the IPv6 library is not found. IPv6 support is compiled only if the system passes all the tests. Finally, some comments in the stack type check are changed to allow them to appear in configure as well as configure.in. 3. configure.in.patch3 does whitespace normalization for this section of configure.in. This patch may solve the problem raised in Bug 553000; I experienced shell errors testing the various paths through the stack type check / library check until I quoted the shell variables in the library check. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-04 08:39 Message: Logged In: YES user_id=21627 I see, so it fails because you have glibc 2.1. Then this is clearly an error in the spec file; there is no need to pass --enable-ipv6 on Linux. There are various other cases where configure exits, e.g. when computation of sizes of builtin types fails, or if relative paths are specified for --prefix etc. They are just less likely to happen. Sean Reifschneider will update the .spec file in this matter, so I'll reject the patch. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-10-03 22:58 Message: Logged In: YES user_id=149084 > Can you please elaborate on how precisely the build > fails on your system, and precisely what software you > are using (operating system, C library)? Linux float.attbi.com 2.2.5-15 RH 6.2(+) glibc-2.1.3-23 glibc-devel-2.1.3-23 [kbk@float ~]$ rpm -qi python2 Name : python2 Relocations: /usr Version : 2.2.1 Vendor: (none) Release : 2 Build Date: Sat Sep 28 01:11:35 2002 Install date: Sat Sep 28 01:41:58 2002 Build Host: float.attbi.com Group : Development/Languages Source RPM: python2-2.2.1-2.src.rpm Excerpt from the build log: ================== checking for usconfig in -lmpc... no checking for thr_create in -lthread... no checking if --enable-ipv6 is specified... yes checking ipv6 stack type... linux-glibc checking for --with-cycle-gc... yes checking for --with-pymalloc... no [...] building '_socket' extension /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c: In function `make\sockaddr': /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c:733: structure has\ no member named `sin6_scope_id' /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c: In function `gets\ockaddrarg': /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c:846: structure has\ no member named `sin6_scope_id' /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c: In function `PySo\cket_getnameinfo': /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c:2598: structure ha\s no member named `sin6_scope_id' gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DUSE_SSL=1 -I. -I/usr/loca\l/src/rpm/BUILD/Python-2.2.1/./Include -I/usr/local/include -IInclude/ -c /usr/\local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c -o build/temp.linux-i68\6-2.2/socketmodule.o WARNING: building of extension "_socket" failed: command 'gcc' failed with exit\ status 1 =================== ** Because the .spec sets the --enable-ipv6 the AF_INET6 and RFC2553 tests were skipped. _socket.so was not created, but the build continued with no socket support at all. ** If I run ./configure --enable-ipv6=no _socket.so is built as follows: ====================== building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DUSE_SSL=1 -I. -I/usr/loca\l/src/rpm/BUILD/Python-2.2.1/./Include -I/usr/local/include -IInclude/ -c /usr/\local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c -o build/temp.linux-i68\6-2.2/socketmodule.o gcc -shared build/temp.linux-i686-2.2/socketmodule.o -L/usr/local/lib -lssl -lc\rypto -o build/lib.linux-i686-2.2/_socket.so ========================== ** If I run ./configure with no switch, I get the same. The AF_INET6 test fails (silently) and I get IPv4. > It is the fallback to ignore the option that bothers > me. The current configure is designed to stop the > build process if a command line option has been > provided, yet the requested feature cannot be > activated. I see what you're saying. OTOH, it appears that the IPv6 configuration is the only part of configure that will terminate the configure script if a test fails. (buggygetaddrinfo also exits on failure). If this is really desired, one could insert an exit in the AC_MSG_CHECKING(if IPv6 can be configured) code if ipv6=0 (one of the four tests failed) _and_ the switch was enabled. > Errors should never pass silently. Unless explicitly > silenced. I'm not sure the user knows that he is silencing any errors. The configure --help merely states that --enable-ipv6=yes will enable IPv6, not that any tests will be bypassed. > If you don't want IPv6 support, build with > --disable-ipv6. yes > If you don't care, build with no option. yes > If you absolutely must have IPv6, configure with > --enable-ipv6. except that you can't have it if you don't have the libraries and runtime support. (Unless there is something going on here that I don't know about :) Sorry this is so long but you asked :-) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 21:12 Message: Logged In: YES user_id=21627 Can you please elaborate on how precisely the build fails on your system, and precisely what software you are using (operating system, C library)? It is the fallback to ignore the option that bothers me. The current configure is designed to stop the build process if a command line option has been provided, yet the requested feature cannot be activated. Errors should never pass silently. Unless explicitly silenced. If you don't want IPv6 support, build with --disable-ipv6. If you don't care, build with no option. If you absolutely must have IPv6, configure with --enable-ipv6. Seems logical to me. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-10-03 20:38 Message: Logged In: YES user_id=149084 Why have configure force a build which is going to fail, or lack runtime support? I guess I'm missing something here :-\ Is the main reason for the switch to provide a way to disable IPv6, or is there also a reason to override the AF_INET6 and RFC2553 tests? The patch ensures that those two tests are run even if the switch is explicitly set, informs the user what the problem is if for some reason the requested IPv6 support cannot be supplied, and provides a graceful fall-back to IPv4. Looking at this again, the current default if no switch is supplied is to attempt to configure IPv6. I chose no IPv6 support; I can provide an updated patch. The spec file is from the current 2.2.1 src.rpm http://www.python.org/2.2.1/rpms.html and Python Patch 611191. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 17:53 Message: Logged In: YES user_id=21627 I fail to see the bug being fixed. An explicit --enable-ipv6 is meant to request explicitly request IPv6 support, overriding the automatic test that happens if you don't provide an option. So the right solution appears to be to change the spec file. I don't know where you got that spec file from, so I can't help here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617906&group_id=5470 From noreply@sourceforge.net Fri Oct 4 08:36:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 00:36:23 -0700 Subject: [Patches] [ python-Patches-618135 ] gzip.py and files > 2G Message-ID: Patches item #618135, was opened at 2002-10-03 18:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=618135&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Geert Jansen (geertj) Assigned to: Nobody/Anonymous (nobody) Summary: gzip.py and files > 2G Initial Comment: Problem: Currently, the gzip module is not able to work with files > 2G uncompressed. The source of the problem is that at the end of a .gz file, there is a trailer containing a 32 bit length field. This field is of course unable to represent a file length > 4G. Because of mixed type arithmetic in gzip.py, this limit is lowered to 2G. Testcase: python gzip.py # must be > 2G python gzip.py -d # error Proposed fix: Test the uncompressed data size modulo 4G. A patch implementing this fix is attached. This is also the solution that gzip itself uses. Two other remarks: I don't understand lines 22-23 of gzip.py: why is the test: "if value < 0" necessary when writing an unsigned int? The testing of the crc value in GzipFile._read_eof() is done modulo 4G. Is this necessary? crc32 is just read from the file as a normal int, and self.crc is from zlib.crc which always returns a regular int. Regards, Geert Jansen ---------------------------------------------------------------------- >Comment By: Geert Jansen (geertj) Date: 2002-10-04 09:36 Message: Logged In: YES user_id=537938 Sorry -- it seems the file upload went wrong! Second try. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=618135&group_id=5470 From noreply@sourceforge.net Fri Oct 4 11:17:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 03:17:49 -0700 Subject: [Patches] [ python-Patches-618347 ] pthread header fix for Solaris 2.6 Message-ID: Patches item #618347, was opened at 2002-10-04 04:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=618347&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jeff Bauer (jeffbauer) Assigned to: Martin v. Löwis (loewis) Summary: pthread header fix for Solaris 2.6 Initial Comment: This is a fix for bug item #617878. It's a bug in the pthread header of Solaris 2.6. According to Martin v. Löwis this problem only occurs in 2.6. Later versions don't use destructor in the header file. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-04 12:17 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed (with modifications) as configure 1.339; 1.279.6.13; configure.in 1.350; 1.288.6.13; pyconfig.h.in 1.50; 1.20.8.2; thread_pthread.h 2.41; 2.36.8.2; ---------------------------------------------------------------------- Comment By: Jeff Bauer (jeffbauer) Date: 2002-10-04 04:22 Message: Logged In: YES user_id=458828 Argh! Patch manager won't allow me to delete/replace the bad diff file. Ignore the first one with the timestamp of 2002-10-03 21:06 and use the second file instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=618347&group_id=5470 From noreply@sourceforge.net Fri Oct 4 11:42:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 03:42:39 -0700 Subject: [Patches] [ python-Patches-617311 ] Tiny profiling info (Psyco #2) Message-ID: Patches item #617311, was opened at 2002-10-01 23:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617311&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Tiny profiling info (Psyco #2) Initial Comment: Psyco-friendly patch #2. A very very small statistic-collecting patch. pystate.h: added a field at the end of the PyThreadStruct: int tick_counter; ceval.c: eval_frame(): tstate->tick_counter is incremented whenever the check_interval ticker reaches zero. The purpose is to give a useful measure of the number of interpreted bytecode instructions in a given thread. This extremely lightweight statistic collector can be of interest to profilers (like psyco.jit()). We can safely guess that a single integer increment every 100 interpreted bytecode instructions will go entierely unnoticed in any performance measure. [This is true for pystone.py.] ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-10-04 10:42 Message: Logged In: YES user_id=6656 I see no harm in this. Are you sure it's actually going to be useful, though? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617311&group_id=5470 From noreply@sourceforge.net Fri Oct 4 11:43:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 03:43:56 -0700 Subject: [Patches] [ python-Patches-617309 ] getframe hook (Psyco #1) Message-ID: Patches item #617309, was opened at 2002-10-01 23:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617309&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: getframe hook (Psyco #1) Initial Comment: Psyco-friendly patch #1 Allow Psyco-like extension modules to quickly plug their own notion of frame call stack into Python, for the use of the interpreter's parts that rely on the call stack for context information. For example, the code that creates a new class implicitely reads the top frame's globals if the class does not explicitely defines a __module__ attribute. With this new hook, Psyco can provide such code with the expected frame object. pystate.h: The PyThreadState structure has a new field added at its end: Py_getframehook getframe; where typedef PyFrameObject *(*Py_getframehook)(PyThreadState *, int); This field points to a function that returns the nth frame object in the call stack. By default, it points to a standard function that starts with tstate->frame and walks their f_back fields, just like the implementation of sys._getframe(). The purpose of this is to allow Psyco to hook another function at this point, in order to lazily emulate the frame objects that correspond to frames executed by Psyco. sysmodule.c: sys_getframe() calls the hook. ceval.c: PyEval_GetFrame() calls the hook. various other places in ceval.c: replaced PyThreadState_Get()->frame with PyEval_GetFrame() so that the hook will be called. pyexpat.c: replaced a PyThreadState_Get()->frame->f_globals with PyEval_GetGlobals(). Note that there are other places using 'frame' and the 'f_back' pointers which have not been changed because they are concerned with actual (classical) bytecode interpretation. The hook is only used in places that are interested in obtaining contextual information (like what the previous frame's globals are), not in places that actually builds frames in which bytecode will be interpreted. Compatibility: third-party extension modules directly reading frame, like Expat before this patch, will exhibit a marginally wrong behavior with Psyco until they are modified to call the hook (or better the "official" interpreter routines that are modified to so do). It does not break anything at all as long as we are not using Psyco. Performance overhead: one more indirect call isn't heavy. More importantly, I don't expect the concerned functions to be used more than occasionally in any code. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-10-04 10:43 Message: Logged In: YES user_id=6656 I'd be uneasy about a change of this subtlety going into the 2.2 branch. Aren't there other ways you can do this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617309&group_id=5470 From noreply@sourceforge.net Fri Oct 4 15:36:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 07:36:53 -0700 Subject: [Patches] [ python-Patches-617311 ] Tiny profiling info (Psyco #2) Message-ID: Patches item #617311, was opened at 2002-10-01 23:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617311&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) >Assigned to: Guido van Rossum (gvanrossum) Summary: Tiny profiling info (Psyco #2) Initial Comment: Psyco-friendly patch #2. A very very small statistic-collecting patch. pystate.h: added a field at the end of the PyThreadStruct: int tick_counter; ceval.c: eval_frame(): tstate->tick_counter is incremented whenever the check_interval ticker reaches zero. The purpose is to give a useful measure of the number of interpreted bytecode instructions in a given thread. This extremely lightweight statistic collector can be of interest to profilers (like psyco.jit()). We can safely guess that a single integer increment every 100 interpreted bytecode instructions will go entierely unnoticed in any performance measure. [This is true for pystone.py.] ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2002-10-04 14:36 Message: Logged In: YES user_id=4771 It is the only way I could work out so far that can "predict" how much a function will be accelerated when run under Psyco. This is a very precious indication for an automatic Psyco-binder. The following table shows the results with the various test functions of the distribution's "test.py" file: (fn name) (speed-up) (bytecode insns per second) f1 106.00 2310545 f4 11.33 2819100 f5 12.08 2992445 f6 1.35 412022 f7 2.24 1331353 f7bis 10.29 1632296 The third column is '(tick_counter * check_interval) / execution_time'. The correlation between the two columns is admittedly not perfect, but still we can see that it was not worthy to try and accelerate f6 because it didn't spend a lot of time actually interpreting bytecodes. Note that similar information could be obtained by setting a line-tracing hook, counting not instructions but lines (which is less precise but still a good approximation). However, line tracing is *much* too slow for anything but debugging usage. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-04 10:42 Message: Logged In: YES user_id=6656 I see no harm in this. Are you sure it's actually going to be useful, though? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617311&group_id=5470 From noreply@sourceforge.net Fri Oct 4 16:46:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 08:46:16 -0700 Subject: [Patches] [ python-Patches-617309 ] getframe hook (Psyco #1) Message-ID: Patches item #617309, was opened at 2002-10-01 23:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617309&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: getframe hook (Psyco #1) Initial Comment: Psyco-friendly patch #1 Allow Psyco-like extension modules to quickly plug their own notion of frame call stack into Python, for the use of the interpreter's parts that rely on the call stack for context information. For example, the code that creates a new class implicitely reads the top frame's globals if the class does not explicitely defines a __module__ attribute. With this new hook, Psyco can provide such code with the expected frame object. pystate.h: The PyThreadState structure has a new field added at its end: Py_getframehook getframe; where typedef PyFrameObject *(*Py_getframehook)(PyThreadState *, int); This field points to a function that returns the nth frame object in the call stack. By default, it points to a standard function that starts with tstate->frame and walks their f_back fields, just like the implementation of sys._getframe(). The purpose of this is to allow Psyco to hook another function at this point, in order to lazily emulate the frame objects that correspond to frames executed by Psyco. sysmodule.c: sys_getframe() calls the hook. ceval.c: PyEval_GetFrame() calls the hook. various other places in ceval.c: replaced PyThreadState_Get()->frame with PyEval_GetFrame() so that the hook will be called. pyexpat.c: replaced a PyThreadState_Get()->frame->f_globals with PyEval_GetGlobals(). Note that there are other places using 'frame' and the 'f_back' pointers which have not been changed because they are concerned with actual (classical) bytecode interpretation. The hook is only used in places that are interested in obtaining contextual information (like what the previous frame's globals are), not in places that actually builds frames in which bytecode will be interpreted. Compatibility: third-party extension modules directly reading frame, like Expat before this patch, will exhibit a marginally wrong behavior with Psyco until they are modified to call the hook (or better the "official" interpreter routines that are modified to so do). It does not break anything at all as long as we are not using Psyco. Performance overhead: one more indirect call isn't heavy. More importantly, I don't expect the concerned functions to be used more than occasionally in any code. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2002-10-04 15:46 Message: Logged In: YES user_id=4771 Here is a simpler patch doing only the one thing that I really cannot work around in Psyco (and I've tried, believe me!) : a way to hook my own replacement function for PyEval_GetFrame(). No more sysmodule change. Just a few places here and there with 'PyThreadState_Get()->frame' replaced with 'PyEval_GetFrame()' so that my hook will trigger. Is the new patch clean enough ? If so I'll assign it to Guido for review. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-04 10:43 Message: Logged In: YES user_id=6656 I'd be uneasy about a change of this subtlety going into the 2.2 branch. Aren't there other ways you can do this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617309&group_id=5470 From noreply@sourceforge.net Fri Oct 4 17:51:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 09:51:29 -0700 Subject: [Patches] [ python-Patches-527371 ] Fix for sre bug 470582 Message-ID: Patches item #527371, was opened at 2002-03-08 04:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=527371&group_id=5470 Category: Modules Group: None Status: Open Resolution: Accepted Priority: 8 Submitted By: Greg Chapman (glchapman) Assigned to: Fredrik Lundh (effbot) Summary: Fix for sre bug 470582 Initial Comment: Bug report 470582 points out that nested groups can produces matches in sre even if the groups within which they are nested do not match: >>> m = sre.search(r"^((\d)\:)?(\d\d)\.(\d\d\d) $", "34.123") >>> m.groups() (None, '3', '34', '123') >>> m = pre.search(r"^((\d)\:)?(\d\d)\.(\d\d\d) $", "34.123") >>> m.groups() (None, None, '34', '123') I believe this is because in the handling of SRE_OP_MAX_UNTIL, state->lastmark is being reduced (after "((\d)\:)" fails) without NULLing out the now- invalid entries at the end of the state->mark array. In the other two cases where state->lastmark is reduced (specifically in SRE_OP_BRANCH and SRE_OP_REPEAT_ONE) memset is used to NULL out the entries at the end of the array. The attached patch does the same thing for the SRE_OP_MAX_UNTIL case. This fixes the above case and does not break anything in test_re.py. ---------------------------------------------------------------------- >Comment By: Greg Chapman (glchapman) Date: 2002-10-04 08:51 Message: Logged In: YES user_id=86307 Assuming this patch is acceptable (I see it has not yet been applied to _sre.c), I wonder if it would be a good candidate for a backport to 2.2.2? (Though it still lacks a fix for the lastindex problem.) ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2002-08-12 13:17 Message: Logged In: YES user_id=86307 I noticed recently that the lastindex attribute of match objects is now documented, so I believe that the lastindex problem I described in my March 8 posting needs to be fixed. Simply, lastindex may claim that a group matched when in fact it didn't (because lastindex does not get updated when lastmark is reset to a lower value): >>> m = sre.match('(\d)?\d\d', '12') >>> m.groups() (None,) >>> m.lastindex 1 ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2002-07-12 03:11 Message: Logged In: YES user_id=38376 (bumped priority as a reminder to self) /F ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-08 09:28 Message: Logged In: YES user_id=31435 Assigned to /F -- he's the expert here. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2002-03-08 06:23 Message: Logged In: YES user_id=86307 I'm pretty sure the memset is correct; state->lastmark is the index of last mark written to (not the index of the next potential write). Also, it occurred to me that there is another related error here: >>> m = sre.search(r'^((\d)\:)?\d\d\.\d\d\d$', '34.123') >>> m.groups() (None, None) >>> m.lastindex 2 In other words, lastindex claims that group 2 was the last that matched, even though it didn't really match. Since lastindex is undocumented, this probably doesn't matter too much. Still, it probably should be reset if it is pointing to a group which gets "unmatched" when state->lastmark is reduced. Perhaps a function like the following should be added for use in the three places where state->lastmark is reset to a previous value: void lastmark_restore(SRE_STATE *state, int lastmark) { assert(lastmark >= 0); if (state->lastmark > lastmark) { int lastvalidindex = (lastmark == 0) ? -1 : (lastmark-1)/2+1; if (state->lastindex > lastvalidindex) state->lastindex = lastvalidindex; memset( state->mark + lastmark + 1, 0, (state->lastmark - lastmark) * sizeof(void*) ); } state->lastmark = lastmark; } ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-03-08 04:29 Message: Logged In: YES user_id=33168 Confirmed that the test w/o fix fails and the test passes with the fix to _sre.c. But I'm not sure if the memset can go too far: memset(state->mark + lastmark + 1, 0, (state->lastmark - lastmark) * sizeof(void*)); I can try under purify, but that doesn't guarantee anything. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2002-03-08 04:20 Message: Logged In: YES user_id=86307 I forgot: here's a patch for re_tests.py which adds the case from the bug report as a test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=527371&group_id=5470 From noreply@sourceforge.net Fri Oct 4 21:32:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 13:32:00 -0700 Subject: [Patches] [ python-Patches-617906 ] Build Error on Systems Without IPv6 Supp Message-ID: Patches item #617906, was opened at 2002-10-02 23:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617906&group_id=5470 Category: Build Group: Python 2.2.x Status: Closed Resolution: Rejected Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Nobody/Anonymous (nobody) Summary: Build Error on Systems Without IPv6 Supp Initial Comment: The problem was discovered installing 2.2.1 from the src.rpm on a Redhat 6.2 system which does not have IPv6 support. The 17 Sept 02 revision of python-2.2.spec (2.2.1-2) defaults to building Python with the configure switch --enable-ipv6=yes. An AC_ARG_ENABLE macro in configure.in sets ENABLE_IPV6 if the config switch is set, without checking whether the system has the resources to build and run IPv6. This forces a compile with IPV6 support which fails on my system. Python then ends up without any socket support since .../lib-dynload/_socket.so is missing. Among other problems, this AC_ARG_ENABLE logic re-exposes Bug 454493. For clarity, the patch is provided in three stages, meant to be applied in sequence: 1. configure.in.patch1 supplies the minimum to move the AF_INET6 and RFC2553 tests out of the ACTION_IF_NOT_GIVEN section of the macro. A default of no IPv6 support is supplied. 2. configure.in.patch2 integrates the stack type and IPv6 library presence tests into the logic which sets ENABLE_IPV6. Trace messages are added to the test for IPv6 library presence. The logic is changed so that the build will default to IPv4 instead of exiting the configuration process if the IPv6 library is not found. IPv6 support is compiled only if the system passes all the tests. Finally, some comments in the stack type check are changed to allow them to appear in configure as well as configure.in. 3. configure.in.patch3 does whitespace normalization for this section of configure.in. This patch may solve the problem raised in Bug 553000; I experienced shell errors testing the various paths through the stack type check / library check until I quoted the shell variables in the library check. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2002-10-04 15:32 Message: Logged In: YES user_id=149084 Well, I'm disappointed that you are rejecting the patch completely. It does more than just tighten up the enable-ipv6 logic. Among other things, there are additional configure messages and I believe a bug in the library presence check code has been fixed. What would you say if I were to update it with the following changes? 1. Make configuring IPv6 the default when the switch is absent. 2. Exit from the configure script if --enable-ipv6=yes but the four tests don't all run successfully. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-04 01:39 Message: Logged In: YES user_id=21627 I see, so it fails because you have glibc 2.1. Then this is clearly an error in the spec file; there is no need to pass --enable-ipv6 on Linux. There are various other cases where configure exits, e.g. when computation of sizes of builtin types fails, or if relative paths are specified for --prefix etc. They are just less likely to happen. Sean Reifschneider will update the .spec file in this matter, so I'll reject the patch. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-10-03 15:58 Message: Logged In: YES user_id=149084 > Can you please elaborate on how precisely the build > fails on your system, and precisely what software you > are using (operating system, C library)? Linux float.attbi.com 2.2.5-15 RH 6.2(+) glibc-2.1.3-23 glibc-devel-2.1.3-23 [kbk@float ~]$ rpm -qi python2 Name : python2 Relocations: /usr Version : 2.2.1 Vendor: (none) Release : 2 Build Date: Sat Sep 28 01:11:35 2002 Install date: Sat Sep 28 01:41:58 2002 Build Host: float.attbi.com Group : Development/Languages Source RPM: python2-2.2.1-2.src.rpm Excerpt from the build log: ================== checking for usconfig in -lmpc... no checking for thr_create in -lthread... no checking if --enable-ipv6 is specified... yes checking ipv6 stack type... linux-glibc checking for --with-cycle-gc... yes checking for --with-pymalloc... no [...] building '_socket' extension /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c: In function `make\sockaddr': /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c:733: structure has\ no member named `sin6_scope_id' /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c: In function `gets\ockaddrarg': /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c:846: structure has\ no member named `sin6_scope_id' /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c: In function `PySo\cket_getnameinfo': /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c:2598: structure ha\s no member named `sin6_scope_id' gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DUSE_SSL=1 -I. -I/usr/loca\l/src/rpm/BUILD/Python-2.2.1/./Include -I/usr/local/include -IInclude/ -c /usr/\local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c -o build/temp.linux-i68\6-2.2/socketmodule.o WARNING: building of extension "_socket" failed: command 'gcc' failed with exit\ status 1 =================== ** Because the .spec sets the --enable-ipv6 the AF_INET6 and RFC2553 tests were skipped. _socket.so was not created, but the build continued with no socket support at all. ** If I run ./configure --enable-ipv6=no _socket.so is built as follows: ====================== building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DUSE_SSL=1 -I. -I/usr/loca\l/src/rpm/BUILD/Python-2.2.1/./Include -I/usr/local/include -IInclude/ -c /usr/\local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c -o build/temp.linux-i68\6-2.2/socketmodule.o gcc -shared build/temp.linux-i686-2.2/socketmodule.o -L/usr/local/lib -lssl -lc\rypto -o build/lib.linux-i686-2.2/_socket.so ========================== ** If I run ./configure with no switch, I get the same. The AF_INET6 test fails (silently) and I get IPv4. > It is the fallback to ignore the option that bothers > me. The current configure is designed to stop the > build process if a command line option has been > provided, yet the requested feature cannot be > activated. I see what you're saying. OTOH, it appears that the IPv6 configuration is the only part of configure that will terminate the configure script if a test fails. (buggygetaddrinfo also exits on failure). If this is really desired, one could insert an exit in the AC_MSG_CHECKING(if IPv6 can be configured) code if ipv6=0 (one of the four tests failed) _and_ the switch was enabled. > Errors should never pass silently. Unless explicitly > silenced. I'm not sure the user knows that he is silencing any errors. The configure --help merely states that --enable-ipv6=yes will enable IPv6, not that any tests will be bypassed. > If you don't want IPv6 support, build with > --disable-ipv6. yes > If you don't care, build with no option. yes > If you absolutely must have IPv6, configure with > --enable-ipv6. except that you can't have it if you don't have the libraries and runtime support. (Unless there is something going on here that I don't know about :) Sorry this is so long but you asked :-) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 14:12 Message: Logged In: YES user_id=21627 Can you please elaborate on how precisely the build fails on your system, and precisely what software you are using (operating system, C library)? It is the fallback to ignore the option that bothers me. The current configure is designed to stop the build process if a command line option has been provided, yet the requested feature cannot be activated. Errors should never pass silently. Unless explicitly silenced. If you don't want IPv6 support, build with --disable-ipv6. If you don't care, build with no option. If you absolutely must have IPv6, configure with --enable-ipv6. Seems logical to me. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-10-03 13:38 Message: Logged In: YES user_id=149084 Why have configure force a build which is going to fail, or lack runtime support? I guess I'm missing something here :-\ Is the main reason for the switch to provide a way to disable IPv6, or is there also a reason to override the AF_INET6 and RFC2553 tests? The patch ensures that those two tests are run even if the switch is explicitly set, informs the user what the problem is if for some reason the requested IPv6 support cannot be supplied, and provides a graceful fall-back to IPv4. Looking at this again, the current default if no switch is supplied is to attempt to configure IPv6. I chose no IPv6 support; I can provide an updated patch. The spec file is from the current 2.2.1 src.rpm http://www.python.org/2.2.1/rpms.html and Python Patch 611191. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 10:53 Message: Logged In: YES user_id=21627 I fail to see the bug being fixed. An explicit --enable-ipv6 is meant to request explicitly request IPv6 support, overriding the automatic test that happens if you don't provide an option. So the right solution appears to be to change the spec file. I don't know where you got that spec file from, so I can't help here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617906&group_id=5470 From noreply@sourceforge.net Fri Oct 4 22:14:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 14:14:17 -0700 Subject: [Patches] [ python-Patches-617906 ] Build Error on Systems Without IPv6 Supp Message-ID: Patches item #617906, was opened at 2002-10-03 06:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617906&group_id=5470 Category: Build Group: Python 2.2.x Status: Closed Resolution: Rejected Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Nobody/Anonymous (nobody) Summary: Build Error on Systems Without IPv6 Supp Initial Comment: The problem was discovered installing 2.2.1 from the src.rpm on a Redhat 6.2 system which does not have IPv6 support. The 17 Sept 02 revision of python-2.2.spec (2.2.1-2) defaults to building Python with the configure switch --enable-ipv6=yes. An AC_ARG_ENABLE macro in configure.in sets ENABLE_IPV6 if the config switch is set, without checking whether the system has the resources to build and run IPv6. This forces a compile with IPV6 support which fails on my system. Python then ends up without any socket support since .../lib-dynload/_socket.so is missing. Among other problems, this AC_ARG_ENABLE logic re-exposes Bug 454493. For clarity, the patch is provided in three stages, meant to be applied in sequence: 1. configure.in.patch1 supplies the minimum to move the AF_INET6 and RFC2553 tests out of the ACTION_IF_NOT_GIVEN section of the macro. A default of no IPv6 support is supplied. 2. configure.in.patch2 integrates the stack type and IPv6 library presence tests into the logic which sets ENABLE_IPV6. Trace messages are added to the test for IPv6 library presence. The logic is changed so that the build will default to IPv4 instead of exiting the configuration process if the IPv6 library is not found. IPv6 support is compiled only if the system passes all the tests. Finally, some comments in the stack type check are changed to allow them to appear in configure as well as configure.in. 3. configure.in.patch3 does whitespace normalization for this section of configure.in. This patch may solve the problem raised in Bug 553000; I experienced shell errors testing the various paths through the stack type check / library check until I quoted the shell variables in the library check. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-04 23:14 Message: Logged In: YES user_id=21627 Unless you can demonstrate a real bug, I won't accept any patches for Python 2.2; this is for bug fixes only. For Python 2.3, there is an entirely different story. Patches are fine, if: - they are against the Python CVS - they are accompanied of a rationale explaining the problem they intend to fix, or the feature they intend to introduce, - are minimal in this respect: one patch at a time, which only solves the demonstrated problem, or only provides a single feature. For your proposed change: 1. I believe this is already the case; IPv6 *is* the default if nothing is specified, and an IPv6 library is detected. 2. I would not like such a change: there is always a chance that the C library will support the API nicely, but configure fails to foresee that it will work out. On such a system, users need a way to try out IPv6. I have real difficulties to understand your changes, and I don't want to guess for 2.2. If you are unhappy with that, we can certainly reopen this patch, so another reviewer can look at it. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-10-04 22:32 Message: Logged In: YES user_id=149084 Well, I'm disappointed that you are rejecting the patch completely. It does more than just tighten up the enable-ipv6 logic. Among other things, there are additional configure messages and I believe a bug in the library presence check code has been fixed. What would you say if I were to update it with the following changes? 1. Make configuring IPv6 the default when the switch is absent. 2. Exit from the configure script if --enable-ipv6=yes but the four tests don't all run successfully. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-04 08:39 Message: Logged In: YES user_id=21627 I see, so it fails because you have glibc 2.1. Then this is clearly an error in the spec file; there is no need to pass --enable-ipv6 on Linux. There are various other cases where configure exits, e.g. when computation of sizes of builtin types fails, or if relative paths are specified for --prefix etc. They are just less likely to happen. Sean Reifschneider will update the .spec file in this matter, so I'll reject the patch. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-10-03 22:58 Message: Logged In: YES user_id=149084 > Can you please elaborate on how precisely the build > fails on your system, and precisely what software you > are using (operating system, C library)? Linux float.attbi.com 2.2.5-15 RH 6.2(+) glibc-2.1.3-23 glibc-devel-2.1.3-23 [kbk@float ~]$ rpm -qi python2 Name : python2 Relocations: /usr Version : 2.2.1 Vendor: (none) Release : 2 Build Date: Sat Sep 28 01:11:35 2002 Install date: Sat Sep 28 01:41:58 2002 Build Host: float.attbi.com Group : Development/Languages Source RPM: python2-2.2.1-2.src.rpm Excerpt from the build log: ================== checking for usconfig in -lmpc... no checking for thr_create in -lthread... no checking if --enable-ipv6 is specified... yes checking ipv6 stack type... linux-glibc checking for --with-cycle-gc... yes checking for --with-pymalloc... no [...] building '_socket' extension /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c: In function `make\sockaddr': /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c:733: structure has\ no member named `sin6_scope_id' /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c: In function `gets\ockaddrarg': /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c:846: structure has\ no member named `sin6_scope_id' /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c: In function `PySo\cket_getnameinfo': /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c:2598: structure ha\s no member named `sin6_scope_id' gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DUSE_SSL=1 -I. -I/usr/loca\l/src/rpm/BUILD/Python-2.2.1/./Include -I/usr/local/include -IInclude/ -c /usr/\local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c -o build/temp.linux-i68\6-2.2/socketmodule.o WARNING: building of extension "_socket" failed: command 'gcc' failed with exit\ status 1 =================== ** Because the .spec sets the --enable-ipv6 the AF_INET6 and RFC2553 tests were skipped. _socket.so was not created, but the build continued with no socket support at all. ** If I run ./configure --enable-ipv6=no _socket.so is built as follows: ====================== building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DUSE_SSL=1 -I. -I/usr/loca\l/src/rpm/BUILD/Python-2.2.1/./Include -I/usr/local/include -IInclude/ -c /usr/\local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c -o build/temp.linux-i68\6-2.2/socketmodule.o gcc -shared build/temp.linux-i686-2.2/socketmodule.o -L/usr/local/lib -lssl -lc\rypto -o build/lib.linux-i686-2.2/_socket.so ========================== ** If I run ./configure with no switch, I get the same. The AF_INET6 test fails (silently) and I get IPv4. > It is the fallback to ignore the option that bothers > me. The current configure is designed to stop the > build process if a command line option has been > provided, yet the requested feature cannot be > activated. I see what you're saying. OTOH, it appears that the IPv6 configuration is the only part of configure that will terminate the configure script if a test fails. (buggygetaddrinfo also exits on failure). If this is really desired, one could insert an exit in the AC_MSG_CHECKING(if IPv6 can be configured) code if ipv6=0 (one of the four tests failed) _and_ the switch was enabled. > Errors should never pass silently. Unless explicitly > silenced. I'm not sure the user knows that he is silencing any errors. The configure --help merely states that --enable-ipv6=yes will enable IPv6, not that any tests will be bypassed. > If you don't want IPv6 support, build with > --disable-ipv6. yes > If you don't care, build with no option. yes > If you absolutely must have IPv6, configure with > --enable-ipv6. except that you can't have it if you don't have the libraries and runtime support. (Unless there is something going on here that I don't know about :) Sorry this is so long but you asked :-) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 21:12 Message: Logged In: YES user_id=21627 Can you please elaborate on how precisely the build fails on your system, and precisely what software you are using (operating system, C library)? It is the fallback to ignore the option that bothers me. The current configure is designed to stop the build process if a command line option has been provided, yet the requested feature cannot be activated. Errors should never pass silently. Unless explicitly silenced. If you don't want IPv6 support, build with --disable-ipv6. If you don't care, build with no option. If you absolutely must have IPv6, configure with --enable-ipv6. Seems logical to me. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-10-03 20:38 Message: Logged In: YES user_id=149084 Why have configure force a build which is going to fail, or lack runtime support? I guess I'm missing something here :-\ Is the main reason for the switch to provide a way to disable IPv6, or is there also a reason to override the AF_INET6 and RFC2553 tests? The patch ensures that those two tests are run even if the switch is explicitly set, informs the user what the problem is if for some reason the requested IPv6 support cannot be supplied, and provides a graceful fall-back to IPv4. Looking at this again, the current default if no switch is supplied is to attempt to configure IPv6. I chose no IPv6 support; I can provide an updated patch. The spec file is from the current 2.2.1 src.rpm http://www.python.org/2.2.1/rpms.html and Python Patch 611191. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 17:53 Message: Logged In: YES user_id=21627 I fail to see the bug being fixed. An explicit --enable-ipv6 is meant to request explicitly request IPv6 support, overriding the automatic test that happens if you don't provide an option. So the right solution appears to be to change the spec file. I don't know where you got that spec file from, so I can't help here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617906&group_id=5470 From noreply@sourceforge.net Sat Oct 5 00:43:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 16:43:02 -0700 Subject: [Patches] [ python-Patches-618791 ] [mingw patches] alloca and posixmodule Message-ID: Patches item #618791, was opened at 2002-10-05 01:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=618791&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Häring (ghaering) Assigned to: Nobody/Anonymous (nobody) Summary: [mingw patches] alloca and posixmodule Initial Comment: This is the first patch in a series of patching of porting Python to native win32, while still using the autoconf-based build process. The compiler used is mingw, the build environment used is msys, a stripped down Cygwin from the mingw project. This patch does several things: * change _alloca to alloca for both mingw and Visual C++, to avoid unnecessary #ifdef-ing. * Change the makesetup shell script to work for win32, where for some weird reason we have a module 'nt' built from a posixmodule.c file. * Change on occurence of #ifdef MS_WINDOWS in posixmodule.c where it should really have been #ifdef Py_WIN_WIDE_FILENAMES * Change the #ifdefs in posixmodule.c so that it can be built with both MSVC and mingw The result of this patch is that we can build a statically built python.exe with a simple ./configure make under mingw/msys. There's, however, still of additional work to do until we can build a native win32 Python with the autoconf-based build process. Please apply this ASAP, as I want to avoid having a diverging Python tree on my harddisk (this makes patch creation a lot more difficult). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=618791&group_id=5470 From noreply@sourceforge.net Sat Oct 5 00:44:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 16:44:06 -0700 Subject: [Patches] [ python-Patches-618791 ] [mingw patches] alloca and posixmodule Message-ID: Patches item #618791, was opened at 2002-10-05 01:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=618791&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Gerhard Häring (ghaering) >Assigned to: Guido van Rossum (gvanrossum) Summary: [mingw patches] alloca and posixmodule Initial Comment: This is the first patch in a series of patching of porting Python to native win32, while still using the autoconf-based build process. The compiler used is mingw, the build environment used is msys, a stripped down Cygwin from the mingw project. This patch does several things: * change _alloca to alloca for both mingw and Visual C++, to avoid unnecessary #ifdef-ing. * Change the makesetup shell script to work for win32, where for some weird reason we have a module 'nt' built from a posixmodule.c file. * Change on occurence of #ifdef MS_WINDOWS in posixmodule.c where it should really have been #ifdef Py_WIN_WIDE_FILENAMES * Change the #ifdefs in posixmodule.c so that it can be built with both MSVC and mingw The result of this patch is that we can build a statically built python.exe with a simple ./configure make under mingw/msys. There's, however, still of additional work to do until we can build a native win32 Python with the autoconf-based build process. Please apply this ASAP, as I want to avoid having a diverging Python tree on my harddisk (this makes patch creation a lot more difficult). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=618791&group_id=5470 From noreply@sourceforge.net Sat Oct 5 10:47:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Oct 2002 02:47:08 -0700 Subject: [Patches] [ python-Patches-594001 ] PEP 277: Unicode file name support Message-ID: Patches item #594001, was opened at 2002-08-12 13:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 Category: Windows Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Mark Hammond (mhammond) Summary: PEP 277: Unicode file name support Initial Comment: This patch is in an updated version of the patch [1] mentioned in the PEP. In addition to merging it with the CVS, it fixes a few formatting problems. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 11:47 Message: Logged In: YES user_id=21627 /cvsroot/python/python/dist/src/Doc/lib/libos.tex,v <-- libos.tex new revision: 1.97; previous revision: 1.96 done Checking in Misc/NEWS; /cvsroot/python/python/dist/src/Misc/NEWS,v <-- NEWS new revision: 1.493; previous revision: 1.492 ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-04 01:53 Message: Logged In: YES user_id=14198 I will try and fix my sf.net mail - in tne meantime Neal, if you could forward them to my skippinet address I will address them. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-04 01:43 Message: Logged In: YES user_id=33168 Mark, I had a bunch of code review notes I sent to python-checkins. I'm not sure you saw them, since my mail to you @ users.sf.net apparently doesn't want to go out. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-04 01:15 Message: Logged In: YES user_id=14198 /cvsroot/python/python/dist/src/Lib/test/test_pep277.py,v <-- test_pep277.py initial revision: 1.1 RCS file: /cvsroot/python/python/dist/src/Lib/test/output/test_pep277,v /cvsroot/python/python/dist/src/Lib/test/output/test_pep277,v <-- test_pep277 initial revision: 1.1 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 10:08 Message: Logged In: YES user_id=21627 Generating the output file with -g and committing it is the right thing to do. I noticed that a .sort call is missing parenthesis, which would need to be added. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-03 09:00 Message: Logged In: YES user_id=14198 Oops - I missed checking in Lib/test/test_pep277.py. With this file in place, the test suite fails for me: test_pep277 test test_pep277 produced unexpected output: ... However, I seem to recall that new tests do not need output files. Should I use the old technique of "regrtest -g ..." and check both the test and output file in, or is there something else I should be doing? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-03 07:15 Message: Logged In: YES user_id=14198 /cvsroot/python/python/dist/src/Include/pyerrors.h,v <-- pyerrors.h new revision: 2.61; previous revision: 2.60 /cvsroot/python/python/dist/src/Lib/test/test_unicode_file.py,v <-- test_unicode_file.py new revision: 1.6; previous revision: 1.5 /cvsroot/python/python/dist/src/Modules/posixmodule.c,v <-- posixmodule.c new revision: 2.261; previous revision: 2.260 /cvsroot/python/python/dist/src/Objects/fileobject.c,v <-- fileobject.c new revision: 2.169; previous revision: 2.168 /cvsroot/python/python/dist/src/PC/pyconfig.h,v <-- pyconfig.h new revision: 1.15; previous revision: 1.14 /cvsroot/python/python/dist/src/Python/errors.c,v <-- errors.c new revision: 2.72; previous revision: 2.71 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-01 19:41 Message: Logged In: YES user_id=21627 The patch passes the test suite on Solaris. I've also attached a documentation change, so I think the patch is ready now. Back to Mark for checkin. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-01 11:59 Message: Logged In: YES user_id=14198 The block: + if (!wpath1 || !wpath2) + return NULL; Should include Py_XDECREF calls for wpath1 and wpath2. Can't be bothered with a new patch just for this :) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-01 01:48 Message: Logged In: YES user_id=14198 Although SF implies otherwise, a bad filename in a submission appears to only prevent the file being uploaded - the rest of the comments etc come through. Hence my double-comments and strange status changes you can see. So, back to Martin as I don't think he is waiting on me for anything. Happy to check in if you like, but would like to see someone run a debug build of this through Linux first to see if any asserts fire - some asserts did indeed fire in the first version of this patch, and Linux may trigger others, or even the 2 that I added. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 14:54 Message: Logged In: YES user_id=14198 Sorry - not sure what I was thinking - obviously can't check in a patch known to crash the test suite! Attaching a new patch - fixes the problem I mentioned with test_unicode_files.py, fixes an error I introduced where the "WithFilename" error functions could be passed a NULL filename, and adding an assert to match the one I added previously. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 14:52 Message: Logged In: YES user_id=14198 Sorry - not sure what I was thinking - obviously can't check in a patch known to crash the test suite! Attaching a new patch. This fixes the crash in test_unicode_file I mentioned. It also fixes another error I introduced where PyErr_SetWithFilename functions can have NULL filenames. Also added an assert for symmetry with one I added before. Martin - back to me if you want me to check it in. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 14:21 Message: Logged In: YES user_id=14198 I missed the fact this was re-assigned to me - should I check my new patch in? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 14:20 Message: Logged In: YES user_id=14198 I get an exception running test_unicode_file.py - we end up with a MBCS encoded string passed to PyUnicode_FromEncodedObject(), that attempts to decode using the system default encoding rather than the file-system default. The error is a NULL pointer deref so should be obvious - unfortunately the fix requires a local reimplementation of PyUnicode_FromEncodedObject(), passing an explicit encoding for string objects. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 12:43 Message: Logged In: YES user_id=21627 Thanks for your comments, just shouting at me to correct all these problems would have been fine :-) In what case do you still get an exception? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 08:35 Message: Logged In: YES user_id=14198 Back to martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 08:34 Message: Logged In: YES user_id=14198 Back to Martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 08:33 Message: Logged In: YES user_id=14198 Uploading text file with my comments on the patch. Also uploading a new patch with these corrections and even better (?) error handling. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 03:03 Message: Logged In: YES user_id=14198 Will review this instant - sorry for the delay. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 08:24 Message: Logged In: YES user_id=21627 Mark, can you please indicate whether you will review this patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-25 21:43 Message: Logged In: YES user_id=31435 Sorry, Martin, bouncing back to Mark -- I really don't know anything about the Windows filename APIs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 17:31 Message: Logged In: YES user_id=21627 Tim, can you review this? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 14:06 Message: Logged In: YES user_id=21627 This is a new version: - wrapped all Windows wide API code with #ifdef Py_WIN_WIDE_FILENAMES - added test case Mark, can you please take a look at this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-12 15:38 Message: Logged In: YES user_id=6380 I'd make unicode_filenames() a macro that expands to 0 on platforms without this wart. I'd also test for wfunc!=NULL before calling unicode_filenames(). There's a lot of hairy code here. Are you sure that there are test cases in the test suite that exercise all of it? Aren't there some #ifdefs missing? posix_[12]str have code that's only relevant for Windows but isn't #ifdef'ed out like it is elsewhere. There should probably be a separate #define in pyport.h to test for this that's equivalent to defined(MS_WINDOWS) && !defined(Py_UNICODE_WIDE), so this can be uniformly tested to see whether this code is necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 From noreply@sourceforge.net Sat Oct 5 16:11:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Oct 2002 08:11:09 -0700 Subject: [Patches] [ python-Patches-617309 ] getframe hook (Psyco #1) Message-ID: Patches item #617309, was opened at 2002-10-01 23:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617309&group_id=5470 Category: Core (C code) >Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) >Assigned to: Guido van Rossum (gvanrossum) Summary: getframe hook (Psyco #1) Initial Comment: Psyco-friendly patch #1 Allow Psyco-like extension modules to quickly plug their own notion of frame call stack into Python, for the use of the interpreter's parts that rely on the call stack for context information. For example, the code that creates a new class implicitely reads the top frame's globals if the class does not explicitely defines a __module__ attribute. With this new hook, Psyco can provide such code with the expected frame object. pystate.h: The PyThreadState structure has a new field added at its end: Py_getframehook getframe; where typedef PyFrameObject *(*Py_getframehook)(PyThreadState *, int); This field points to a function that returns the nth frame object in the call stack. By default, it points to a standard function that starts with tstate->frame and walks their f_back fields, just like the implementation of sys._getframe(). The purpose of this is to allow Psyco to hook another function at this point, in order to lazily emulate the frame objects that correspond to frames executed by Psyco. sysmodule.c: sys_getframe() calls the hook. ceval.c: PyEval_GetFrame() calls the hook. various other places in ceval.c: replaced PyThreadState_Get()->frame with PyEval_GetFrame() so that the hook will be called. pyexpat.c: replaced a PyThreadState_Get()->frame->f_globals with PyEval_GetGlobals(). Note that there are other places using 'frame' and the 'f_back' pointers which have not been changed because they are concerned with actual (classical) bytecode interpretation. The hook is only used in places that are interested in obtaining contextual information (like what the previous frame's globals are), not in places that actually builds frames in which bytecode will be interpreted. Compatibility: third-party extension modules directly reading frame, like Expat before this patch, will exhibit a marginally wrong behavior with Psyco until they are modified to call the hook (or better the "official" interpreter routines that are modified to so do). It does not break anything at all as long as we are not using Psyco. Performance overhead: one more indirect call isn't heavy. More importantly, I don't expect the concerned functions to be used more than occasionally in any code. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-04 15:46 Message: Logged In: YES user_id=4771 Here is a simpler patch doing only the one thing that I really cannot work around in Psyco (and I've tried, believe me!) : a way to hook my own replacement function for PyEval_GetFrame(). No more sysmodule change. Just a few places here and there with 'PyThreadState_Get()->frame' replaced with 'PyEval_GetFrame()' so that my hook will trigger. Is the new patch clean enough ? If so I'll assign it to Guido for review. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-04 10:43 Message: Logged In: YES user_id=6656 I'd be uneasy about a change of this subtlety going into the 2.2 branch. Aren't there other ways you can do this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617309&group_id=5470 From noreply@sourceforge.net Sat Oct 5 16:12:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Oct 2002 08:12:08 -0700 Subject: [Patches] [ python-Patches-617311 ] Tiny profiling info (Psyco #2) Message-ID: Patches item #617311, was opened at 2002-10-01 23:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617311&group_id=5470 Category: Core (C code) >Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Guido van Rossum (gvanrossum) Summary: Tiny profiling info (Psyco #2) Initial Comment: Psyco-friendly patch #2. A very very small statistic-collecting patch. pystate.h: added a field at the end of the PyThreadStruct: int tick_counter; ceval.c: eval_frame(): tstate->tick_counter is incremented whenever the check_interval ticker reaches zero. The purpose is to give a useful measure of the number of interpreted bytecode instructions in a given thread. This extremely lightweight statistic collector can be of interest to profilers (like psyco.jit()). We can safely guess that a single integer increment every 100 interpreted bytecode instructions will go entierely unnoticed in any performance measure. [This is true for pystone.py.] ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-04 14:36 Message: Logged In: YES user_id=4771 It is the only way I could work out so far that can "predict" how much a function will be accelerated when run under Psyco. This is a very precious indication for an automatic Psyco-binder. The following table shows the results with the various test functions of the distribution's "test.py" file: (fn name) (speed-up) (bytecode insns per second) f1 106.00 2310545 f4 11.33 2819100 f5 12.08 2992445 f6 1.35 412022 f7 2.24 1331353 f7bis 10.29 1632296 The third column is '(tick_counter * check_interval) / execution_time'. The correlation between the two columns is admittedly not perfect, but still we can see that it was not worthy to try and accelerate f6 because it didn't spend a lot of time actually interpreting bytecodes. Note that similar information could be obtained by setting a line-tracing hook, counting not instructions but lines (which is less precise but still a good approximation). However, line tracing is *much* too slow for anything but debugging usage. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-04 10:42 Message: Logged In: YES user_id=6656 I see no harm in this. Are you sure it's actually going to be useful, though? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617311&group_id=5470 From noreply@sourceforge.net Sat Oct 5 16:12:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Oct 2002 08:12:42 -0700 Subject: [Patches] [ python-Patches-617312 ] debugger-controlled jumps (Psyco #3) Message-ID: Patches item #617312, was opened at 2002-10-01 23:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617312&group_id=5470 Category: Core (C code) >Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Guido van Rossum (gvanrossum) Summary: debugger-controlled jumps (Psyco #3) Initial Comment: Psyco-friendly patch #3. Allows the C profile and trace functions (called upon function entry, line tracing, function exit, and exception) to alter some fields of the current PyFrameObject to influence the execution of the main loop. This is currently impossible because all the relevant fields are copied into local variables of eval_frame(), shadowing any subsequence change in the frame object. This is designed for what I plan to do with Psyco, but could also be used by advanced debuggers to allow the execution point to be modified by the user. Besides, the patch is just a matter of swapping a few lines in eval_frame(), introducing almost no extra complexity. In ceval.c:eval_frame(): The calls to call_trace(...PyTrace_CALL...) at the beginning of the code have been moved above the initialization of the local variables, allowing the trace functions to fiddle with the frame object before the main loop sees it. There is also a bug fix here: if the profile or trace functions raise an error at this point, eval_frame() used to quit without restoring tstate->frame and tstate->recursion_depth. [XXX should have been a bug report on its own] Finally, the call_trace() on SET_LINENO has been slightly modified to allow the trace function to move the execution point elsewhere. This is done by saving a few local variables are saved to and restored from the frame object around the call_trace(). The variables are the current instruction pointer (which was already saved in f->f_lasti, but is now restored from f->f_lasti too), and the current stack_pointer. Compatibility: f->f_stacktop normally remains NULL for the whole execution of the frame. This patch sets it to a non-NULL value for the duration of the call to the line-by-line trace function. I expect this not to cause any incompatibility because f->f_stacktop is not visible from Python code. I do not expect extension modules to rely on this detail. Note however that this has an influence on the GC, which only visits the stack if f->f_stacktop is set. Again, I assume this is not an issue -- it cannot even cause dead cycles to be detected earlier by the GC because as long as we are in the call_trace() call, we have a live reference to f. Performance: when tracing is on, SET_LINENO is now marginally slower. I guess this is not considered as an issue given the debugging nature of tracing. In Python 2.3, line tracing is currently *much* heavier and nobody seems to complain ;-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-03 08:50 Message: Logged In: YES user_id=6656 Fair enough. Let's see what Guido thinks. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-02 20:33 Message: Logged In: YES user_id=4771 The trace function can change f_lasti if it knows what it does and if it accordingly changes all other fields too, like f_stacktop, f_blockstack and f_iblock. In fact, f_lasti and f_stacktop are the only fields of the frame objects that are currently cached in local variables (with the exception of what concerns the f_code object itself) so that this patch is enough to let the trace function actually move the execution point elsewhere. This would be quite useful in Psyco, if the rest of the function has been emulated and we then want the main loop to exit with the proper value: just move f_lasti just before the RETURN_VALUE opcode, clean up the stack and block stack, and push the already-computed result value where RETURN_VALUE will find it. Psyco could also execute just a part of the function and give it back to Python at some later position. A "clean hack". ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-02 13:14 Message: Logged In: YES user_id=6656 Never mind, the bug offended me so much that I fixed it both on the trunk and the 22-maint branch. Python/ceval.c revisions 2.337 and 2.301.4.5 Lib/test/test_trace.py revisions 1.4 and 1.4.2.1 (probably a 2.1 bugix candidate, if any cares...) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-02 12:23 Message: Logged In: YES user_id=6656 What about the blockstack? Are you just relying on trace functions not moving f_lasti unwisely? Agree about the bug. Do you have a test case for it? Otherwise I'll cook one up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617312&group_id=5470 From noreply@sourceforge.net Sun Oct 6 02:13:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Oct 2002 18:13:44 -0700 Subject: [Patches] [ python-Patches-619108 ] Fix test_pep277 on Win9x Message-ID: Patches item #619108, was opened at 2002-10-06 11:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619108&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Martin v. Löwis (loewis) Summary: Fix test_pep277 on Win9x Initial Comment: In the interests of getting test_pep277 running for Tim , sys.getwindowsversion() should be added. Chose sys as that is where all other version related information is found. Happy to move to the os module is desired, but posixmodule.c is enough of a mess already. Patch even includes doc :) Martin, could you please review? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619108&group_id=5470 From noreply@sourceforge.net Sun Oct 6 08:25:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 00:25:34 -0700 Subject: [Patches] [ python-Patches-619108 ] Fix test_pep277 on Win9x Message-ID: Patches item #619108, was opened at 2002-10-06 03:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619108&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Martin v. Löwis (loewis) Summary: Fix test_pep277 on Win9x Initial Comment: In the interests of getting test_pep277 running for Tim , sys.getwindowsversion() should be added. Chose sys as that is where all other version related information is found. Happy to move to the os module is desired, but posixmodule.c is enough of a mess already. Patch even includes doc :) Martin, could you please review? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 09:25 Message: Logged In: YES user_id=21627 I'm in favour of adding sys.getwindowsversion. As for disabling the test, it seems like Tim prefers to add sys.path.supports_unicode_filenames, with the following settings: posixpath, macpath, dospath, os2emxpath: False ntpath: getwindowsversion() < 0x80000000 I'm somewhat confused about the signedness of GetVersion(), though - it appears that it is unsigned in C. If so, I think the Python wrapper should also return non-negative numbers only. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619108&group_id=5470 From noreply@sourceforge.net Sun Oct 6 12:41:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 04:41:17 -0700 Subject: [Patches] [ python-Patches-619108 ] Fix test_pep277 on Win9x Message-ID: Patches item #619108, was opened at 2002-10-06 03:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619108&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Martin v. Löwis (loewis) Summary: Fix test_pep277 on Win9x Initial Comment: In the interests of getting test_pep277 running for Tim , sys.getwindowsversion() should be added. Chose sys as that is where all other version related information is found. Happy to move to the os module is desired, but posixmodule.c is enough of a mess already. Patch even includes doc :) Martin, could you please review? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 13:41 Message: Logged In: YES user_id=21627 Attached is a patch that uses getwindowsversion as I just suggested. Back to Mark for comments and possible checkin. The libsys.tex change also needs a \versionadded. If sys.getwindowsversion remains signed, this patch must be adjusted. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 09:25 Message: Logged In: YES user_id=21627 I'm in favour of adding sys.getwindowsversion. As for disabling the test, it seems like Tim prefers to add sys.path.supports_unicode_filenames, with the following settings: posixpath, macpath, dospath, os2emxpath: False ntpath: getwindowsversion() < 0x80000000 I'm somewhat confused about the signedness of GetVersion(), though - it appears that it is unsigned in C. If so, I think the Python wrapper should also return non-negative numbers only. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619108&group_id=5470 From noreply@sourceforge.net Sun Oct 6 12:41:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 04:41:38 -0700 Subject: [Patches] [ python-Patches-619108 ] Fix test_pep277 on Win9x Message-ID: Patches item #619108, was opened at 2002-10-06 03:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619108&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) >Assigned to: Mark Hammond (mhammond) Summary: Fix test_pep277 on Win9x Initial Comment: In the interests of getting test_pep277 running for Tim , sys.getwindowsversion() should be added. Chose sys as that is where all other version related information is found. Happy to move to the os module is desired, but posixmodule.c is enough of a mess already. Patch even includes doc :) Martin, could you please review? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 13:41 Message: Logged In: YES user_id=21627 Attached is a patch that uses getwindowsversion as I just suggested. Back to Mark for comments and possible checkin. The libsys.tex change also needs a \versionadded. If sys.getwindowsversion remains signed, this patch must be adjusted. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 09:25 Message: Logged In: YES user_id=21627 I'm in favour of adding sys.getwindowsversion. As for disabling the test, it seems like Tim prefers to add sys.path.supports_unicode_filenames, with the following settings: posixpath, macpath, dospath, os2emxpath: False ntpath: getwindowsversion() < 0x80000000 I'm somewhat confused about the signedness of GetVersion(), though - it appears that it is unsigned in C. If so, I think the Python wrapper should also return non-negative numbers only. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619108&group_id=5470 From noreply@sourceforge.net Sun Oct 6 12:53:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 04:53:07 -0700 Subject: [Patches] [ python-Patches-619108 ] Fix test_pep277 on Win9x Message-ID: Patches item #619108, was opened at 2002-10-05 21:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619108&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) >Assigned to: Martin v. Löwis (loewis) Summary: Fix test_pep277 on Win9x Initial Comment: In the interests of getting test_pep277 running for Tim , sys.getwindowsversion() should be added. Chose sys as that is where all other version related information is found. Happy to move to the os module is desired, but posixmodule.c is enough of a mess already. Patch even includes doc :) Martin, could you please review? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-06 07:53 Message: Logged In: YES user_id=6380 Did you mean sys, or os? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 07:41 Message: Logged In: YES user_id=21627 Attached is a patch that uses getwindowsversion as I just suggested. Back to Mark for comments and possible checkin. The libsys.tex change also needs a \versionadded. If sys.getwindowsversion remains signed, this patch must be adjusted. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 03:25 Message: Logged In: YES user_id=21627 I'm in favour of adding sys.getwindowsversion. As for disabling the test, it seems like Tim prefers to add sys.path.supports_unicode_filenames, with the following settings: posixpath, macpath, dospath, os2emxpath: False ntpath: getwindowsversion() < 0x80000000 I'm somewhat confused about the signedness of GetVersion(), though - it appears that it is unsigned in C. If so, I think the Python wrapper should also return non-negative numbers only. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619108&group_id=5470 From noreply@sourceforge.net Sun Oct 6 13:18:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 05:18:55 -0700 Subject: [Patches] [ python-Patches-619108 ] Fix test_pep277 on Win9x Message-ID: Patches item #619108, was opened at 2002-10-06 03:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619108&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Martin v. Löwis (loewis) Summary: Fix test_pep277 on Win9x Initial Comment: In the interests of getting test_pep277 running for Tim , sys.getwindowsversion() should be added. Chose sys as that is where all other version related information is found. Happy to move to the os module is desired, but posixmodule.c is enough of a mess already. Patch even includes doc :) Martin, could you please review? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 14:18 Message: Logged In: YES user_id=21627 Mark wants it to be in sys; I have no preference in either direction. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-06 13:53 Message: Logged In: YES user_id=6380 Did you mean sys, or os? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 13:41 Message: Logged In: YES user_id=21627 Attached is a patch that uses getwindowsversion as I just suggested. Back to Mark for comments and possible checkin. The libsys.tex change also needs a \versionadded. If sys.getwindowsversion remains signed, this patch must be adjusted. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 09:25 Message: Logged In: YES user_id=21627 I'm in favour of adding sys.getwindowsversion. As for disabling the test, it seems like Tim prefers to add sys.path.supports_unicode_filenames, with the following settings: posixpath, macpath, dospath, os2emxpath: False ntpath: getwindowsversion() < 0x80000000 I'm somewhat confused about the signedness of GetVersion(), though - it appears that it is unsigned in C. If so, I think the Python wrapper should also return non-negative numbers only. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619108&group_id=5470 From noreply@sourceforge.net Sun Oct 6 13:19:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 05:19:53 -0700 Subject: [Patches] [ python-Patches-619108 ] Fix test_pep277 on Win9x Message-ID: Patches item #619108, was opened at 2002-10-06 03:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619108&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) >Assigned to: Mark Hammond (mhammond) Summary: Fix test_pep277 on Win9x Initial Comment: In the interests of getting test_pep277 running for Tim , sys.getwindowsversion() should be added. Chose sys as that is where all other version related information is found. Happy to move to the os module is desired, but posixmodule.c is enough of a mess already. Patch even includes doc :) Martin, could you please review? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 14:18 Message: Logged In: YES user_id=21627 Mark wants it to be in sys; I have no preference in either direction. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-06 13:53 Message: Logged In: YES user_id=6380 Did you mean sys, or os? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 13:41 Message: Logged In: YES user_id=21627 Attached is a patch that uses getwindowsversion as I just suggested. Back to Mark for comments and possible checkin. The libsys.tex change also needs a \versionadded. If sys.getwindowsversion remains signed, this patch must be adjusted. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 09:25 Message: Logged In: YES user_id=21627 I'm in favour of adding sys.getwindowsversion. As for disabling the test, it seems like Tim prefers to add sys.path.supports_unicode_filenames, with the following settings: posixpath, macpath, dospath, os2emxpath: False ntpath: getwindowsversion() < 0x80000000 I'm somewhat confused about the signedness of GetVersion(), though - it appears that it is unsigned in C. If so, I think the Python wrapper should also return non-negative numbers only. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619108&group_id=5470 From noreply@sourceforge.net Sun Oct 6 14:30:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 06:30:19 -0700 Subject: [Patches] [ python-Patches-619108 ] Fix test_pep277 on Win9x Message-ID: Patches item #619108, was opened at 2002-10-05 21:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619108&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: Fix test_pep277 on Win9x Initial Comment: In the interests of getting test_pep277 running for Tim , sys.getwindowsversion() should be added. Chose sys as that is where all other version related information is found. Happy to move to the os module is desired, but posixmodule.c is enough of a mess already. Patch even includes doc :) Martin, could you please review? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-06 09:30 Message: Logged In: YES user_id=6380 But sys.path.supports_unicode_filenames was a typo, right? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 08:18 Message: Logged In: YES user_id=21627 Mark wants it to be in sys; I have no preference in either direction. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-06 07:53 Message: Logged In: YES user_id=6380 Did you mean sys, or os? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 07:41 Message: Logged In: YES user_id=21627 Attached is a patch that uses getwindowsversion as I just suggested. Back to Mark for comments and possible checkin. The libsys.tex change also needs a \versionadded. If sys.getwindowsversion remains signed, this patch must be adjusted. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 03:25 Message: Logged In: YES user_id=21627 I'm in favour of adding sys.getwindowsversion. As for disabling the test, it seems like Tim prefers to add sys.path.supports_unicode_filenames, with the following settings: posixpath, macpath, dospath, os2emxpath: False ntpath: getwindowsversion() < 0x80000000 I'm somewhat confused about the signedness of GetVersion(), though - it appears that it is unsigned in C. If so, I think the Python wrapper should also return non-negative numbers only. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619108&group_id=5470 From noreply@sourceforge.net Sun Oct 6 15:17:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 07:17:32 -0700 Subject: [Patches] [ python-Patches-619108 ] Fix test_pep277 on Win9x Message-ID: Patches item #619108, was opened at 2002-10-06 03:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619108&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: Fix test_pep277 on Win9x Initial Comment: In the interests of getting test_pep277 running for Tim , sys.getwindowsversion() should be added. Chose sys as that is where all other version related information is found. Happy to move to the os module is desired, but posixmodule.c is enough of a mess already. Patch even includes doc :) Martin, could you please review? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 16:17 Message: Logged In: YES user_id=21627 Right; that's os.path.supports_unicode_filenames. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-06 15:30 Message: Logged In: YES user_id=6380 But sys.path.supports_unicode_filenames was a typo, right? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 14:18 Message: Logged In: YES user_id=21627 Mark wants it to be in sys; I have no preference in either direction. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-06 13:53 Message: Logged In: YES user_id=6380 Did you mean sys, or os? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 13:41 Message: Logged In: YES user_id=21627 Attached is a patch that uses getwindowsversion as I just suggested. Back to Mark for comments and possible checkin. The libsys.tex change also needs a \versionadded. If sys.getwindowsversion remains signed, this patch must be adjusted. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 09:25 Message: Logged In: YES user_id=21627 I'm in favour of adding sys.getwindowsversion. As for disabling the test, it seems like Tim prefers to add sys.path.supports_unicode_filenames, with the following settings: posixpath, macpath, dospath, os2emxpath: False ntpath: getwindowsversion() < 0x80000000 I'm somewhat confused about the signedness of GetVersion(), though - it appears that it is unsigned in C. If so, I think the Python wrapper should also return non-negative numbers only. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619108&group_id=5470 From noreply@sourceforge.net Sun Oct 6 18:56:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 10:56:13 -0700 Subject: [Patches] [ python-Patches-572031 ] AUTH method LOGIN for smtplib Message-ID: Patches item #572031, was opened at 2002-06-21 12:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572031&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gerhard Häring (ghaering) Assigned to: Barry A. Warsaw (bwarsaw) Summary: AUTH method LOGIN for smtplib Initial Comment: Unfortunately, my original SMTP auth patch doesn't work so well in real life. There are two methods to advertise the available auth methods for SMTP servers: old-style: AUTH=method1 method2 ... RFC style: AUTH method1 method2 Microsoft's MUAs are b0rken in that they only understand the old-style method. That's why most SMTP servers are configured to advertise their authentication methods in old-style _and_ new style. There are also some especially broken SMTP servers like old M$ Exchange servers that only show their auth methods via the old style. Also the (sadly but true) very widely used M$ Exchange server only supports the LOGIN auth method (I have to use that thing at work, that's why I came up with this patch). Exchange also supports some other proprietary auth methods (NTLM, ...), but we needn't care about these. My argument is that the Python SMTP AUTH support will get a lot more useful to people if we also support 1) the old-style AUTH= advertisement 2) the LOGIN auth method, which, although not standardized via RFCs and originally invented by Netscape, is still in wide use, and for some servers the only method to use them, so we should support it Please note that in the current implementation, if a server uses the old-style AUTH= method, our SMTP auth support simply breaks because of the esmtp_features parsing. I'm randomly assigning this patch to Barry, because AFAIK he knows a lot about email handling. Assign around as you please :-) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 19:56 Message: Logged In: YES user_id=21627 Committed for 2.2 as 1.46.4.5 It appears that Piers Lauder already committed version 2 of the patch as 1.59; I've committed the missing change as 1.63. Please review both committs for correctness. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-25 06:06 Message: Logged In: YES user_id=12800 I've simply not had time to devote to this patch. If you feel so inclined, please take it from me, otherwise I will try to find some time for it soon. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-24 18:16 Message: Logged In: YES user_id=21627 There is another such patch as #613708. It would be good to make progress on this patch. Barry, what is stopping this from being integrated? ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-08-29 16:33 Message: Logged In: YES user_id=163326 Here's a backport for Python 2.2. I did the diff against Python 2.2.1 and hope it still applies to the maintenance line. Arguments for backporting: - missing handling of old-style advertisement is a bug because it makes SMTP auth unusable for a wide range of servers - backporting support for AUTH LOGIN is safe ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-08-06 08:55 Message: Logged In: YES user_id=163326 Uh-oh. I made a stupid error in the code, sending the username twice. One more lesson I learnt: never use username == password for testing :-/ ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-24 15:05 Message: Logged In: YES user_id=21627 In http://sourceforge.net/tracker/?func=detail&atid=105470&aid=581165&group_id=5470 pierslauder reports success with this patch; see his detailed report for remaining problems. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-17 15:39 Message: Logged In: YES user_id=21627 That existing SMTP servers announce LOGIN only in the old-style header is a good reason to support those as well; I hence recommend that this patch is applied. Microsoft is, strictly speaking, conforming to the RFC by *not* reporting LOGIN in the AUTH header: only registered SASL mechanism can be announced there, and LOGIN is not registered; see http://www.iana.org/assignments/sasl-mechanisms ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-07-01 00:34 Message: Logged In: YES user_id=163326 Updated patch. Changes to the previous patch: - Use email.base64MIME.encode to get rid of the added newlines. - Merge old and RFC-style auth methods in self.smtp_features instead of parsing old-style auth lines seperately. - Removed example line for changing auth method priorities (we won't list all permutations of auth methods ;-) - Removed superfluous logging call of chosen auth method. - Moved comment about SMTP features syntax into the right place again. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-06-30 23:14 Message: Logged In: YES user_id=163326 Martin, the reason why we need to take into account both old and RFC-style auth advertisement is that there are some smtp servers, which advertise different auth mechanisms in the old vs. RFC-style line. In particular, the MS Exchange server that I have to use at work and I think that this is even the default configuration of Exchange 2000. In my case, it advertises its LOGIN method only in the AUTH= line. I'll shortly upload a patch that takes this into account. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-30 18:20 Message: Logged In: YES user_id=21627 I still cannot see why support for the old-style AUTH lines is necessary. If all SMTPds announce their supported mechanisms with both syntaxes, why is it then necessary to even look at the old syntax? I'm all for adding support for the LOGIN method. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-06-30 17:59 Message: Logged In: YES user_id=12800 Martin, (some? most?) MUAs post messages by talking directly to their outgoing SMTPd, so that's probably why Gerhard mentions it. On the issue of base64 issue, see the comment in bug #552605, which I just took assignment of. I'll deal with both these bug reports soon. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-30 17:41 Message: Logged In: YES user_id=21627 I cannot understand why the behaviour of MS MUAs is relevant here at all; smtplib only talks to MTAs (or MSAs). If MTAs advertise the AUTH extension in the new syntax in addition to the old syntax, why is it not good to just ignore the old advertisement? Can you point to a specific software package (ideally even a specific host) which fails to interact with the current smtplib correctly? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-06-22 05:53 Message: Logged In: YES user_id=85984 A comment on the old-style advertisement. You say that Microsoft's MUAs only understand the old-style method. I haven't found this to be the case. tmda-ofmipd is an outgoing SMTP proxy that supports SMTP authentication, and I only use the RFC style advertisement. This works perfectly well with MS clients like Outlook 2000, and Outlook Express 5. Below is an example of what the advertisement looks like. BTW, no disagreement about supporting the old-style advertisement in smtplib, as I think it's prudent, just making a point. # telnet aguirre 8025 Trying 172.18.3.5... Connected to aguirre.la.mastaler.com. Escape character is '^]'. 220 aguirre.la.mastaler.com ESMTP tmda-ofmipd EHLO aguirre.la.mastaler.com 250-aguirre.la.mastaler.com 250 AUTH LOGIN CRAM-MD5 PLAIN QUIT 221 Bye Connection closed by foreign host. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-06-21 12:43 Message: Logged In: YES user_id=163326 This also includes a slightly modified version of patch #552605. Even better would IMO be to add an additional parameter to base64.encode* and the corresponding binascii functions that avoids the insertion of newline characters. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572031&group_id=5470 From noreply@sourceforge.net Sun Oct 6 20:19:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 12:19:50 -0700 Subject: [Patches] [ python-Patches-619352 ] Updated .spec file for 2.2.2b1 Message-ID: Patches item #619352, was opened at 2002-10-06 19:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619352&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Updated .spec file for 2.2.2b1 Initial Comment: This patch updates the .spec file to build RPMs for the 2.2.2b1 release. Sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619352&group_id=5470 From noreply@sourceforge.net Sun Oct 6 21:44:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 13:44:42 -0700 Subject: [Patches] [ python-Patches-617312 ] debugger-controlled jumps (Psyco #3) Message-ID: Patches item #617312, was opened at 2002-10-01 19:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617312&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Guido van Rossum (gvanrossum) Summary: debugger-controlled jumps (Psyco #3) Initial Comment: Psyco-friendly patch #3. Allows the C profile and trace functions (called upon function entry, line tracing, function exit, and exception) to alter some fields of the current PyFrameObject to influence the execution of the main loop. This is currently impossible because all the relevant fields are copied into local variables of eval_frame(), shadowing any subsequence change in the frame object. This is designed for what I plan to do with Psyco, but could also be used by advanced debuggers to allow the execution point to be modified by the user. Besides, the patch is just a matter of swapping a few lines in eval_frame(), introducing almost no extra complexity. In ceval.c:eval_frame(): The calls to call_trace(...PyTrace_CALL...) at the beginning of the code have been moved above the initialization of the local variables, allowing the trace functions to fiddle with the frame object before the main loop sees it. There is also a bug fix here: if the profile or trace functions raise an error at this point, eval_frame() used to quit without restoring tstate->frame and tstate->recursion_depth. [XXX should have been a bug report on its own] Finally, the call_trace() on SET_LINENO has been slightly modified to allow the trace function to move the execution point elsewhere. This is done by saving a few local variables are saved to and restored from the frame object around the call_trace(). The variables are the current instruction pointer (which was already saved in f->f_lasti, but is now restored from f->f_lasti too), and the current stack_pointer. Compatibility: f->f_stacktop normally remains NULL for the whole execution of the frame. This patch sets it to a non-NULL value for the duration of the call to the line-by-line trace function. I expect this not to cause any incompatibility because f->f_stacktop is not visible from Python code. I do not expect extension modules to rely on this detail. Note however that this has an influence on the GC, which only visits the stack if f->f_stacktop is set. Again, I assume this is not an issue -- it cannot even cause dead cycles to be detected earlier by the GC because as long as we are in the call_trace() call, we have a live reference to f. Performance: when tracing is on, SET_LINENO is now marginally slower. I guess this is not considered as an issue given the debugging nature of tracing. In Python 2.3, line tracing is currently *much* heavier and nobody seems to complain ;-) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-06 16:44 Message: Logged In: YES user_id=6380 I'd like to get this into 2.2.2, but the patch doesn't apply cleanly (courtesy of MWH fixing the beg reported herein :-). Armin, can you upload a fixed patch? Or if MWH reads this, can you check this and the other two in? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-03 04:50 Message: Logged In: YES user_id=6656 Fair enough. Let's see what Guido thinks. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-02 16:33 Message: Logged In: YES user_id=4771 The trace function can change f_lasti if it knows what it does and if it accordingly changes all other fields too, like f_stacktop, f_blockstack and f_iblock. In fact, f_lasti and f_stacktop are the only fields of the frame objects that are currently cached in local variables (with the exception of what concerns the f_code object itself) so that this patch is enough to let the trace function actually move the execution point elsewhere. This would be quite useful in Psyco, if the rest of the function has been emulated and we then want the main loop to exit with the proper value: just move f_lasti just before the RETURN_VALUE opcode, clean up the stack and block stack, and push the already-computed result value where RETURN_VALUE will find it. Psyco could also execute just a part of the function and give it back to Python at some later position. A "clean hack". ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-02 09:14 Message: Logged In: YES user_id=6656 Never mind, the bug offended me so much that I fixed it both on the trunk and the 22-maint branch. Python/ceval.c revisions 2.337 and 2.301.4.5 Lib/test/test_trace.py revisions 1.4 and 1.4.2.1 (probably a 2.1 bugix candidate, if any cares...) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-02 08:23 Message: Logged In: YES user_id=6656 What about the blockstack? Are you just relying on trace functions not moving f_lasti unwisely? Agree about the bug. Do you have a test case for it? Otherwise I'll cook one up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617312&group_id=5470 From noreply@sourceforge.net Sun Oct 6 21:45:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 13:45:51 -0700 Subject: [Patches] [ python-Patches-617311 ] Tiny profiling info (Psyco #2) Message-ID: Patches item #617311, was opened at 2002-10-01 19:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617311&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Guido van Rossum (gvanrossum) Summary: Tiny profiling info (Psyco #2) Initial Comment: Psyco-friendly patch #2. A very very small statistic-collecting patch. pystate.h: added a field at the end of the PyThreadStruct: int tick_counter; ceval.c: eval_frame(): tstate->tick_counter is incremented whenever the check_interval ticker reaches zero. The purpose is to give a useful measure of the number of interpreted bytecode instructions in a given thread. This extremely lightweight statistic collector can be of interest to profilers (like psyco.jit()). We can safely guess that a single integer increment every 100 interpreted bytecode instructions will go entierely unnoticed in any performance measure. [This is true for pystone.py.] ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-06 16:45 Message: Logged In: YES user_id=6380 I'd like to get this into 2.2.2. MWH, can you check it in? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-04 10:36 Message: Logged In: YES user_id=4771 It is the only way I could work out so far that can "predict" how much a function will be accelerated when run under Psyco. This is a very precious indication for an automatic Psyco-binder. The following table shows the results with the various test functions of the distribution's "test.py" file: (fn name) (speed-up) (bytecode insns per second) f1 106.00 2310545 f4 11.33 2819100 f5 12.08 2992445 f6 1.35 412022 f7 2.24 1331353 f7bis 10.29 1632296 The third column is '(tick_counter * check_interval) / execution_time'. The correlation between the two columns is admittedly not perfect, but still we can see that it was not worthy to try and accelerate f6 because it didn't spend a lot of time actually interpreting bytecodes. Note that similar information could be obtained by setting a line-tracing hook, counting not instructions but lines (which is less precise but still a good approximation). However, line tracing is *much* too slow for anything but debugging usage. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-04 06:42 Message: Logged In: YES user_id=6656 I see no harm in this. Are you sure it's actually going to be useful, though? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617311&group_id=5470 From noreply@sourceforge.net Sun Oct 6 21:46:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 13:46:07 -0700 Subject: [Patches] [ python-Patches-617309 ] getframe hook (Psyco #1) Message-ID: Patches item #617309, was opened at 2002-10-01 19:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617309&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Guido van Rossum (gvanrossum) Summary: getframe hook (Psyco #1) Initial Comment: Psyco-friendly patch #1 Allow Psyco-like extension modules to quickly plug their own notion of frame call stack into Python, for the use of the interpreter's parts that rely on the call stack for context information. For example, the code that creates a new class implicitely reads the top frame's globals if the class does not explicitely defines a __module__ attribute. With this new hook, Psyco can provide such code with the expected frame object. pystate.h: The PyThreadState structure has a new field added at its end: Py_getframehook getframe; where typedef PyFrameObject *(*Py_getframehook)(PyThreadState *, int); This field points to a function that returns the nth frame object in the call stack. By default, it points to a standard function that starts with tstate->frame and walks their f_back fields, just like the implementation of sys._getframe(). The purpose of this is to allow Psyco to hook another function at this point, in order to lazily emulate the frame objects that correspond to frames executed by Psyco. sysmodule.c: sys_getframe() calls the hook. ceval.c: PyEval_GetFrame() calls the hook. various other places in ceval.c: replaced PyThreadState_Get()->frame with PyEval_GetFrame() so that the hook will be called. pyexpat.c: replaced a PyThreadState_Get()->frame->f_globals with PyEval_GetGlobals(). Note that there are other places using 'frame' and the 'f_back' pointers which have not been changed because they are concerned with actual (classical) bytecode interpretation. The hook is only used in places that are interested in obtaining contextual information (like what the previous frame's globals are), not in places that actually builds frames in which bytecode will be interpreted. Compatibility: third-party extension modules directly reading frame, like Expat before this patch, will exhibit a marginally wrong behavior with Psyco until they are modified to call the hook (or better the "official" interpreter routines that are modified to so do). It does not break anything at all as long as we are not using Psyco. Performance overhead: one more indirect call isn't heavy. More importantly, I don't expect the concerned functions to be used more than occasionally in any code. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-06 16:46 Message: Logged In: YES user_id=6380 I'd like to get this int. 2.2.2. MWH, can you check it in? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-04 11:46 Message: Logged In: YES user_id=4771 Here is a simpler patch doing only the one thing that I really cannot work around in Psyco (and I've tried, believe me!) : a way to hook my own replacement function for PyEval_GetFrame(). No more sysmodule change. Just a few places here and there with 'PyThreadState_Get()->frame' replaced with 'PyEval_GetFrame()' so that my hook will trigger. Is the new patch clean enough ? If so I'll assign it to Guido for review. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-04 06:43 Message: Logged In: YES user_id=6656 I'd be uneasy about a change of this subtlety going into the 2.2 branch. Aren't there other ways you can do this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617309&group_id=5470 From noreply@sourceforge.net Sun Oct 6 22:07:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 14:07:05 -0700 Subject: [Patches] [ python-Patches-572031 ] AUTH method LOGIN for smtplib Message-ID: Patches item #572031, was opened at 2002-06-21 12:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572031&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Gerhard Häring (ghaering) Assigned to: Barry A. Warsaw (bwarsaw) Summary: AUTH method LOGIN for smtplib Initial Comment: Unfortunately, my original SMTP auth patch doesn't work so well in real life. There are two methods to advertise the available auth methods for SMTP servers: old-style: AUTH=method1 method2 ... RFC style: AUTH method1 method2 Microsoft's MUAs are b0rken in that they only understand the old-style method. That's why most SMTP servers are configured to advertise their authentication methods in old-style _and_ new style. There are also some especially broken SMTP servers like old M$ Exchange servers that only show their auth methods via the old style. Also the (sadly but true) very widely used M$ Exchange server only supports the LOGIN auth method (I have to use that thing at work, that's why I came up with this patch). Exchange also supports some other proprietary auth methods (NTLM, ...), but we needn't care about these. My argument is that the Python SMTP AUTH support will get a lot more useful to people if we also support 1) the old-style AUTH= advertisement 2) the LOGIN auth method, which, although not standardized via RFCs and originally invented by Netscape, is still in wide use, and for some servers the only method to use them, so we should support it Please note that in the current implementation, if a server uses the old-style AUTH= method, our SMTP auth support simply breaks because of the esmtp_features parsing. I'm randomly assigning this patch to Barry, because AFAIK he knows a lot about email handling. Assign around as you please :-) ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2002-10-06 23:07 Message: Logged In: YES user_id=163326 They both seem to be ok. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 19:56 Message: Logged In: YES user_id=21627 Committed for 2.2 as 1.46.4.5 It appears that Piers Lauder already committed version 2 of the patch as 1.59; I've committed the missing change as 1.63. Please review both committs for correctness. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-25 06:06 Message: Logged In: YES user_id=12800 I've simply not had time to devote to this patch. If you feel so inclined, please take it from me, otherwise I will try to find some time for it soon. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-24 18:16 Message: Logged In: YES user_id=21627 There is another such patch as #613708. It would be good to make progress on this patch. Barry, what is stopping this from being integrated? ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-08-29 16:33 Message: Logged In: YES user_id=163326 Here's a backport for Python 2.2. I did the diff against Python 2.2.1 and hope it still applies to the maintenance line. Arguments for backporting: - missing handling of old-style advertisement is a bug because it makes SMTP auth unusable for a wide range of servers - backporting support for AUTH LOGIN is safe ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-08-06 08:55 Message: Logged In: YES user_id=163326 Uh-oh. I made a stupid error in the code, sending the username twice. One more lesson I learnt: never use username == password for testing :-/ ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-24 15:05 Message: Logged In: YES user_id=21627 In http://sourceforge.net/tracker/?func=detail&atid=105470&aid=581165&group_id=5470 pierslauder reports success with this patch; see his detailed report for remaining problems. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-17 15:39 Message: Logged In: YES user_id=21627 That existing SMTP servers announce LOGIN only in the old-style header is a good reason to support those as well; I hence recommend that this patch is applied. Microsoft is, strictly speaking, conforming to the RFC by *not* reporting LOGIN in the AUTH header: only registered SASL mechanism can be announced there, and LOGIN is not registered; see http://www.iana.org/assignments/sasl-mechanisms ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-07-01 00:34 Message: Logged In: YES user_id=163326 Updated patch. Changes to the previous patch: - Use email.base64MIME.encode to get rid of the added newlines. - Merge old and RFC-style auth methods in self.smtp_features instead of parsing old-style auth lines seperately. - Removed example line for changing auth method priorities (we won't list all permutations of auth methods ;-) - Removed superfluous logging call of chosen auth method. - Moved comment about SMTP features syntax into the right place again. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-06-30 23:14 Message: Logged In: YES user_id=163326 Martin, the reason why we need to take into account both old and RFC-style auth advertisement is that there are some smtp servers, which advertise different auth mechanisms in the old vs. RFC-style line. In particular, the MS Exchange server that I have to use at work and I think that this is even the default configuration of Exchange 2000. In my case, it advertises its LOGIN method only in the AUTH= line. I'll shortly upload a patch that takes this into account. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-30 18:20 Message: Logged In: YES user_id=21627 I still cannot see why support for the old-style AUTH lines is necessary. If all SMTPds announce their supported mechanisms with both syntaxes, why is it then necessary to even look at the old syntax? I'm all for adding support for the LOGIN method. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-06-30 17:59 Message: Logged In: YES user_id=12800 Martin, (some? most?) MUAs post messages by talking directly to their outgoing SMTPd, so that's probably why Gerhard mentions it. On the issue of base64 issue, see the comment in bug #552605, which I just took assignment of. I'll deal with both these bug reports soon. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-30 17:41 Message: Logged In: YES user_id=21627 I cannot understand why the behaviour of MS MUAs is relevant here at all; smtplib only talks to MTAs (or MSAs). If MTAs advertise the AUTH extension in the new syntax in addition to the old syntax, why is it not good to just ignore the old advertisement? Can you point to a specific software package (ideally even a specific host) which fails to interact with the current smtplib correctly? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-06-22 05:53 Message: Logged In: YES user_id=85984 A comment on the old-style advertisement. You say that Microsoft's MUAs only understand the old-style method. I haven't found this to be the case. tmda-ofmipd is an outgoing SMTP proxy that supports SMTP authentication, and I only use the RFC style advertisement. This works perfectly well with MS clients like Outlook 2000, and Outlook Express 5. Below is an example of what the advertisement looks like. BTW, no disagreement about supporting the old-style advertisement in smtplib, as I think it's prudent, just making a point. # telnet aguirre 8025 Trying 172.18.3.5... Connected to aguirre.la.mastaler.com. Escape character is '^]'. 220 aguirre.la.mastaler.com ESMTP tmda-ofmipd EHLO aguirre.la.mastaler.com 250-aguirre.la.mastaler.com 250 AUTH LOGIN CRAM-MD5 PLAIN QUIT 221 Bye Connection closed by foreign host. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-06-21 12:43 Message: Logged In: YES user_id=163326 This also includes a slightly modified version of patch #552605. Even better would IMO be to add an additional parameter to base64.encode* and the corresponding binascii functions that avoids the insertion of newline characters. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572031&group_id=5470 From noreply@sourceforge.net Mon Oct 7 01:28:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 17:28:30 -0700 Subject: [Patches] [ python-Patches-617312 ] debugger-controlled jumps (Psyco #3) Message-ID: Patches item #617312, was opened at 2002-10-01 23:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617312&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Guido van Rossum (gvanrossum) Summary: debugger-controlled jumps (Psyco #3) Initial Comment: Psyco-friendly patch #3. Allows the C profile and trace functions (called upon function entry, line tracing, function exit, and exception) to alter some fields of the current PyFrameObject to influence the execution of the main loop. This is currently impossible because all the relevant fields are copied into local variables of eval_frame(), shadowing any subsequence change in the frame object. This is designed for what I plan to do with Psyco, but could also be used by advanced debuggers to allow the execution point to be modified by the user. Besides, the patch is just a matter of swapping a few lines in eval_frame(), introducing almost no extra complexity. In ceval.c:eval_frame(): The calls to call_trace(...PyTrace_CALL...) at the beginning of the code have been moved above the initialization of the local variables, allowing the trace functions to fiddle with the frame object before the main loop sees it. There is also a bug fix here: if the profile or trace functions raise an error at this point, eval_frame() used to quit without restoring tstate->frame and tstate->recursion_depth. [XXX should have been a bug report on its own] Finally, the call_trace() on SET_LINENO has been slightly modified to allow the trace function to move the execution point elsewhere. This is done by saving a few local variables are saved to and restored from the frame object around the call_trace(). The variables are the current instruction pointer (which was already saved in f->f_lasti, but is now restored from f->f_lasti too), and the current stack_pointer. Compatibility: f->f_stacktop normally remains NULL for the whole execution of the frame. This patch sets it to a non-NULL value for the duration of the call to the line-by-line trace function. I expect this not to cause any incompatibility because f->f_stacktop is not visible from Python code. I do not expect extension modules to rely on this detail. Note however that this has an influence on the GC, which only visits the stack if f->f_stacktop is set. Again, I assume this is not an issue -- it cannot even cause dead cycles to be detected earlier by the GC because as long as we are in the call_trace() call, we have a live reference to f. Performance: when tracing is on, SET_LINENO is now marginally slower. I guess this is not considered as an issue given the debugging nature of tracing. In Python 2.3, line tracing is currently *much* heavier and nobody seems to complain ;-) ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2002-10-07 00:28 Message: Logged In: YES user_id=4771 Here you are! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-06 20:44 Message: Logged In: YES user_id=6380 I'd like to get this into 2.2.2, but the patch doesn't apply cleanly (courtesy of MWH fixing the beg reported herein :-). Armin, can you upload a fixed patch? Or if MWH reads this, can you check this and the other two in? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-03 08:50 Message: Logged In: YES user_id=6656 Fair enough. Let's see what Guido thinks. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-02 20:33 Message: Logged In: YES user_id=4771 The trace function can change f_lasti if it knows what it does and if it accordingly changes all other fields too, like f_stacktop, f_blockstack and f_iblock. In fact, f_lasti and f_stacktop are the only fields of the frame objects that are currently cached in local variables (with the exception of what concerns the f_code object itself) so that this patch is enough to let the trace function actually move the execution point elsewhere. This would be quite useful in Psyco, if the rest of the function has been emulated and we then want the main loop to exit with the proper value: just move f_lasti just before the RETURN_VALUE opcode, clean up the stack and block stack, and push the already-computed result value where RETURN_VALUE will find it. Psyco could also execute just a part of the function and give it back to Python at some later position. A "clean hack". ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-02 13:14 Message: Logged In: YES user_id=6656 Never mind, the bug offended me so much that I fixed it both on the trunk and the 22-maint branch. Python/ceval.c revisions 2.337 and 2.301.4.5 Lib/test/test_trace.py revisions 1.4 and 1.4.2.1 (probably a 2.1 bugix candidate, if any cares...) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-02 12:23 Message: Logged In: YES user_id=6656 What about the blockstack? Are you just relying on trace functions not moving f_lasti unwisely? Agree about the bug. Do you have a test case for it? Otherwise I'll cook one up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617312&group_id=5470 From noreply@sourceforge.net Mon Oct 7 03:33:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 19:33:26 -0700 Subject: [Patches] [ python-Patches-619471 ] C3 MRO algoritm implementation Message-ID: Patches item #619471, was opened at 2002-10-07 04:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619471&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Samuele Pedroni (pedronis) Assigned to: Nobody/Anonymous (nobody) Summary: C3 MRO algoritm implementation Initial Comment: At least is a beginning. On Linux all tests and the modified test_descrt.py pass. A few cases in test_descr.py are commented out, maybe they you be adjusted, reconstructed. Backup logic picking an element from the first non-empty list and removing it from all lists where it appears and just throwing a warning instead of an exception could be put where I set the exception now. Although in the long run people should learn to use consistent hiearchies anyway. PS: I was wondering how to get lst.remove(o) functionality from C, apart through PyObject_CallMethod... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619471&group_id=5470 From noreply@sourceforge.net Mon Oct 7 03:37:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 19:37:40 -0700 Subject: [Patches] [ python-Patches-619472 ] C3 MRO algo impl Message-ID: Patches item #619472, was opened at 2002-10-07 04:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619472&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Samuele Pedroni (pedronis) Assigned to: Nobody/Anonymous (nobody) Summary: C3 MRO algo impl Initial Comment: At least is a beginning. On Linux all tests and the modified test_descrt.py pass. A few cases in test_descr.py are commented out, maybe they you be adjusted, reconstructed. Backup logic picking an element from the first non-empty list and removing it from all lists where it appears and just throwing a warning instead of an exception could be put where I set the exception now. Although in the long run people should learn to use consistent hiearchies anyway. PS: I was wondering how to get lst.remove(o) functionality from C, apart through PyObject_CallMethod... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619472&group_id=5470 From noreply@sourceforge.net Mon Oct 7 03:51:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 19:51:14 -0700 Subject: [Patches] [ python-Patches-619472 ] C3 MRO algo impl Message-ID: Patches item #619472, was opened at 2002-10-07 04:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619472&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open >Resolution: Invalid Priority: 5 Submitted By: Samuele Pedroni (pedronis) Assigned to: Nobody/Anonymous (nobody) Summary: C3 MRO algo impl Initial Comment: At least is a beginning. On Linux all tests and the modified test_descrt.py pass. A few cases in test_descr.py are commented out, maybe they you be adjusted, reconstructed. Backup logic picking an element from the first non-empty list and removing it from all lists where it appears and just throwing a warning instead of an exception could be put where I set the exception now. Although in the long run people should learn to use consistent hiearchies anyway. PS: I was wondering how to get lst.remove(o) functionality from C, apart through PyObject_CallMethod... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619472&group_id=5470 From noreply@sourceforge.net Mon Oct 7 03:52:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 19:52:26 -0700 Subject: [Patches] [ python-Patches-619472 ] C3 MRO algo impl Message-ID: Patches item #619472, was opened at 2002-10-07 04:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619472&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open >Resolution: Rejected Priority: 5 Submitted By: Samuele Pedroni (pedronis) Assigned to: Nobody/Anonymous (nobody) Summary: C3 MRO algo impl Initial Comment: At least is a beginning. On Linux all tests and the modified test_descrt.py pass. A few cases in test_descr.py are commented out, maybe they you be adjusted, reconstructed. Backup logic picking an element from the first non-empty list and removing it from all lists where it appears and just throwing a warning instead of an exception could be put where I set the exception now. Although in the long run people should learn to use consistent hiearchies anyway. PS: I was wondering how to get lst.remove(o) functionality from C, apart through PyObject_CallMethod... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619472&group_id=5470 From noreply@sourceforge.net Mon Oct 7 03:53:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 19:53:08 -0700 Subject: [Patches] [ python-Patches-619472 ] C3 MRO algo impl Message-ID: Patches item #619472, was opened at 2002-10-07 04:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619472&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Deleted Resolution: Rejected Priority: 5 Submitted By: Samuele Pedroni (pedronis) Assigned to: Nobody/Anonymous (nobody) Summary: C3 MRO algo impl Initial Comment: At least is a beginning. On Linux all tests and the modified test_descrt.py pass. A few cases in test_descr.py are commented out, maybe they you be adjusted, reconstructed. Backup logic picking an element from the first non-empty list and removing it from all lists where it appears and just throwing a warning instead of an exception could be put where I set the exception now. Although in the long run people should learn to use consistent hiearchies anyway. PS: I was wondering how to get lst.remove(o) functionality from C, apart through PyObject_CallMethod... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619472&group_id=5470 From noreply@sourceforge.net Mon Oct 7 03:54:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 19:54:32 -0700 Subject: [Patches] [ python-Patches-619471 ] C3 MRO algorithm implementation Message-ID: Patches item #619471, was opened at 2002-10-07 04:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619471&group_id=5470 Category: Core (C code) Group: None >Status: Deleted Resolution: None Priority: 5 Submitted By: Samuele Pedroni (pedronis) Assigned to: Nobody/Anonymous (nobody) >Summary: C3 MRO algorithm implementation Initial Comment: At least is a beginning. On Linux all tests and the modified test_descrt.py pass. A few cases in test_descr.py are commented out, maybe they you be adjusted, reconstructed. Backup logic picking an element from the first non-empty list and removing it from all lists where it appears and just throwing a warning instead of an exception could be put where I set the exception now. Although in the long run people should learn to use consistent hiearchies anyway. PS: I was wondering how to get lst.remove(o) functionality from C, apart through PyObject_CallMethod... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619471&group_id=5470 From noreply@sourceforge.net Mon Oct 7 04:02:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 20:02:42 -0700 Subject: [Patches] [ python-Patches-619475 ] C3 MRO algorithm implementation Message-ID: Patches item #619475, was opened at 2002-10-07 05:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619475&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Samuele Pedroni (pedronis) Assigned to: Nobody/Anonymous (nobody) Summary: C3 MRO algorithm implementation Initial Comment: At least is a beginning. On Linux all tests and the modified test_descr.py pass. A few cases in test_descr.py are commented out, maybe they should be adjusted, reconstructed. For order disagreement situations: backup logic picking an element from the first non-empty list and removing it from all lists, where it appears, and just throwing a warning instead of an exception could be put where I set the exception now. Although in the long run people should learn to use consistent hiearchies anyway. PS: I was wondering how to get/reuse lst.remove(o) functionality from C, apart through PyObject_CallMethod... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619475&group_id=5470 From noreply@sourceforge.net Mon Oct 7 04:05:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 20:05:02 -0700 Subject: [Patches] [ python-Patches-619475 ] C3 MRO algorithm implementation Message-ID: Patches item #619475, was opened at 2002-10-07 05:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619475&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Samuele Pedroni (pedronis) >Assigned to: Guido van Rossum (gvanrossum) Summary: C3 MRO algorithm implementation Initial Comment: At least is a beginning. On Linux all tests and the modified test_descr.py pass. A few cases in test_descr.py are commented out, maybe they should be adjusted, reconstructed. For order disagreement situations: backup logic picking an element from the first non-empty list and removing it from all lists, where it appears, and just throwing a warning instead of an exception could be put where I set the exception now. Although in the long run people should learn to use consistent hiearchies anyway. PS: I was wondering how to get/reuse lst.remove(o) functionality from C, apart through PyObject_CallMethod... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619475&group_id=5470 From noreply@sourceforge.net Mon Oct 7 05:10:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 21:10:33 -0700 Subject: [Patches] [ python-Patches-619493 ] Fix for building RPMs under RH8.0 Message-ID: Patches item #619493, was opened at 2002-10-07 04:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619493&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for building RPMs under RH8.0 Initial Comment: Red Hat 8.0 has removed the build options from the "rpm" binary and migrated into the program "rpmbuild". The included patch changes the command from "rpm" to "rpmbuild" if the file /usr/bin/rpmbuild or /bin/rpmbuild exists. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619493&group_id=5470 From noreply@sourceforge.net Mon Oct 7 05:16:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 21:16:58 -0700 Subject: [Patches] [ python-Patches-619493 ] Fix for building RPMs under RH8.0 Message-ID: Patches item #619493, was opened at 2002-10-07 04:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619493&group_id=5470 Category: Distutils and setup.py >Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for building RPMs under RH8.0 Initial Comment: Red Hat 8.0 has removed the build options from the "rpm" binary and migrated into the program "rpmbuild". The included patch changes the command from "rpm" to "rpmbuild" if the file /usr/bin/rpmbuild or /bin/rpmbuild exists. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619493&group_id=5470 From noreply@sourceforge.net Mon Oct 7 06:51:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 22:51:32 -0700 Subject: [Patches] [ python-Patches-611191 ] Updated .spec file for 2.2 series. Message-ID: Patches item #611191, was opened at 2002-09-18 19:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=611191&group_id=5470 Category: Build Group: Python 2.2.x >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Updated .spec file for 2.2 series. Initial Comment: Attached is a new .spec file which sould be pushed into CVS. Changes include adding a Makefile.pre.in to the -devel package, and fixing the historic lack of a "python2.2" binary when building "python2". Sean ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 07:51 Message: Logged In: YES user_id=21627 Superceded by #619352. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=611191&group_id=5470 From noreply@sourceforge.net Mon Oct 7 06:53:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 22:53:46 -0700 Subject: [Patches] [ python-Patches-619352 ] Updated .spec file for 2.2.2b1 Message-ID: Patches item #619352, was opened at 2002-10-06 21:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619352&group_id=5470 Category: Build Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Updated .spec file for 2.2.2b1 Initial Comment: This patch updates the .spec file to build RPMs for the 2.2.2b1 release. Sean ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 07:53 Message: Logged In: YES user_id=21627 Committed as 1.1.2.3; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619352&group_id=5470 From noreply@sourceforge.net Mon Oct 7 06:58:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 22:58:56 -0700 Subject: [Patches] [ python-Patches-619493 ] Fix for building RPMs under RH8.0 Message-ID: Patches item #619493, was opened at 2002-10-07 06:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619493&group_id=5470 Category: Distutils and setup.py Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for building RPMs under RH8.0 Initial Comment: Red Hat 8.0 has removed the build options from the "rpm" binary and migrated into the program "rpmbuild". The included patch changes the command from "rpm" to "rpmbuild" if the file /usr/bin/rpmbuild or /bin/rpmbuild exists. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 07:58 Message: Logged In: YES user_id=21627 Could it be that the indentation was wrong on this patch, and that you should adjust your tabstop setting to 8? Reindented and applied as 1.27.6.2 and 1.32. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619493&group_id=5470 From noreply@sourceforge.net Mon Oct 7 10:38:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 02:38:12 -0700 Subject: [Patches] [ python-Patches-617312 ] debugger-controlled jumps (Psyco #3) Message-ID: Patches item #617312, was opened at 2002-10-01 23:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617312&group_id=5470 Category: Core (C code) Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Guido van Rossum (gvanrossum) Summary: debugger-controlled jumps (Psyco #3) Initial Comment: Psyco-friendly patch #3. Allows the C profile and trace functions (called upon function entry, line tracing, function exit, and exception) to alter some fields of the current PyFrameObject to influence the execution of the main loop. This is currently impossible because all the relevant fields are copied into local variables of eval_frame(), shadowing any subsequence change in the frame object. This is designed for what I plan to do with Psyco, but could also be used by advanced debuggers to allow the execution point to be modified by the user. Besides, the patch is just a matter of swapping a few lines in eval_frame(), introducing almost no extra complexity. In ceval.c:eval_frame(): The calls to call_trace(...PyTrace_CALL...) at the beginning of the code have been moved above the initialization of the local variables, allowing the trace functions to fiddle with the frame object before the main loop sees it. There is also a bug fix here: if the profile or trace functions raise an error at this point, eval_frame() used to quit without restoring tstate->frame and tstate->recursion_depth. [XXX should have been a bug report on its own] Finally, the call_trace() on SET_LINENO has been slightly modified to allow the trace function to move the execution point elsewhere. This is done by saving a few local variables are saved to and restored from the frame object around the call_trace(). The variables are the current instruction pointer (which was already saved in f->f_lasti, but is now restored from f->f_lasti too), and the current stack_pointer. Compatibility: f->f_stacktop normally remains NULL for the whole execution of the frame. This patch sets it to a non-NULL value for the duration of the call to the line-by-line trace function. I expect this not to cause any incompatibility because f->f_stacktop is not visible from Python code. I do not expect extension modules to rely on this detail. Note however that this has an influence on the GC, which only visits the stack if f->f_stacktop is set. Again, I assume this is not an issue -- it cannot even cause dead cycles to be detected earlier by the GC because as long as we are in the call_trace() call, we have a live reference to f. Performance: when tracing is on, SET_LINENO is now marginally slower. I guess this is not considered as an issue given the debugging nature of tracing. In Python 2.3, line tracing is currently *much* heavier and nobody seems to complain ;-) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-10-07 09:38 Message: Logged In: YES user_id=6656 OK done, in ceval.c revision 2.301.4.6. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-07 00:28 Message: Logged In: YES user_id=4771 Here you are! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-06 20:44 Message: Logged In: YES user_id=6380 I'd like to get this into 2.2.2, but the patch doesn't apply cleanly (courtesy of MWH fixing the beg reported herein :-). Armin, can you upload a fixed patch? Or if MWH reads this, can you check this and the other two in? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-03 08:50 Message: Logged In: YES user_id=6656 Fair enough. Let's see what Guido thinks. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-02 20:33 Message: Logged In: YES user_id=4771 The trace function can change f_lasti if it knows what it does and if it accordingly changes all other fields too, like f_stacktop, f_blockstack and f_iblock. In fact, f_lasti and f_stacktop are the only fields of the frame objects that are currently cached in local variables (with the exception of what concerns the f_code object itself) so that this patch is enough to let the trace function actually move the execution point elsewhere. This would be quite useful in Psyco, if the rest of the function has been emulated and we then want the main loop to exit with the proper value: just move f_lasti just before the RETURN_VALUE opcode, clean up the stack and block stack, and push the already-computed result value where RETURN_VALUE will find it. Psyco could also execute just a part of the function and give it back to Python at some later position. A "clean hack". ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-02 13:14 Message: Logged In: YES user_id=6656 Never mind, the bug offended me so much that I fixed it both on the trunk and the 22-maint branch. Python/ceval.c revisions 2.337 and 2.301.4.5 Lib/test/test_trace.py revisions 1.4 and 1.4.2.1 (probably a 2.1 bugix candidate, if any cares...) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-02 12:23 Message: Logged In: YES user_id=6656 What about the blockstack? Are you just relying on trace functions not moving f_lasti unwisely? Agree about the bug. Do you have a test case for it? Otherwise I'll cook one up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617312&group_id=5470 From noreply@sourceforge.net Mon Oct 7 10:42:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 02:42:13 -0700 Subject: [Patches] [ python-Patches-617311 ] Tiny profiling info (Psyco #2) Message-ID: Patches item #617311, was opened at 2002-10-01 23:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617311&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Guido van Rossum (gvanrossum) Summary: Tiny profiling info (Psyco #2) Initial Comment: Psyco-friendly patch #2. A very very small statistic-collecting patch. pystate.h: added a field at the end of the PyThreadStruct: int tick_counter; ceval.c: eval_frame(): tstate->tick_counter is incremented whenever the check_interval ticker reaches zero. The purpose is to give a useful measure of the number of interpreted bytecode instructions in a given thread. This extremely lightweight statistic collector can be of interest to profilers (like psyco.jit()). We can safely guess that a single integer increment every 100 interpreted bytecode instructions will go entierely unnoticed in any performance measure. [This is true for pystone.py.] ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-10-07 09:42 Message: Logged In: YES user_id=6656 Done in Include/pystate.h revision 2.18.16.1 Python/ceval.c revision 2.301.4.7 Armin, I don't know how you generated this patch, but it would have been easier to apply if it had been rooted in the "src" directory, like e.g.: $ cvs diff Include/pystate.h Python/ceval.c > ~/diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-06 20:45 Message: Logged In: YES user_id=6380 I'd like to get this into 2.2.2. MWH, can you check it in? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-04 14:36 Message: Logged In: YES user_id=4771 It is the only way I could work out so far that can "predict" how much a function will be accelerated when run under Psyco. This is a very precious indication for an automatic Psyco-binder. The following table shows the results with the various test functions of the distribution's "test.py" file: (fn name) (speed-up) (bytecode insns per second) f1 106.00 2310545 f4 11.33 2819100 f5 12.08 2992445 f6 1.35 412022 f7 2.24 1331353 f7bis 10.29 1632296 The third column is '(tick_counter * check_interval) / execution_time'. The correlation between the two columns is admittedly not perfect, but still we can see that it was not worthy to try and accelerate f6 because it didn't spend a lot of time actually interpreting bytecodes. Note that similar information could be obtained by setting a line-tracing hook, counting not instructions but lines (which is less precise but still a good approximation). However, line tracing is *much* too slow for anything but debugging usage. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-04 10:42 Message: Logged In: YES user_id=6656 I see no harm in this. Are you sure it's actually going to be useful, though? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617311&group_id=5470 From noreply@sourceforge.net Mon Oct 7 10:42:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 02:42:29 -0700 Subject: [Patches] [ python-Patches-617311 ] Tiny profiling info (Psyco #2) Message-ID: Patches item #617311, was opened at 2002-10-01 23:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617311&group_id=5470 Category: Core (C code) Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Guido van Rossum (gvanrossum) Summary: Tiny profiling info (Psyco #2) Initial Comment: Psyco-friendly patch #2. A very very small statistic-collecting patch. pystate.h: added a field at the end of the PyThreadStruct: int tick_counter; ceval.c: eval_frame(): tstate->tick_counter is incremented whenever the check_interval ticker reaches zero. The purpose is to give a useful measure of the number of interpreted bytecode instructions in a given thread. This extremely lightweight statistic collector can be of interest to profilers (like psyco.jit()). We can safely guess that a single integer increment every 100 interpreted bytecode instructions will go entierely unnoticed in any performance measure. [This is true for pystone.py.] ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-07 09:42 Message: Logged In: YES user_id=6656 Done in Include/pystate.h revision 2.18.16.1 Python/ceval.c revision 2.301.4.7 Armin, I don't know how you generated this patch, but it would have been easier to apply if it had been rooted in the "src" directory, like e.g.: $ cvs diff Include/pystate.h Python/ceval.c > ~/diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-06 20:45 Message: Logged In: YES user_id=6380 I'd like to get this into 2.2.2. MWH, can you check it in? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-04 14:36 Message: Logged In: YES user_id=4771 It is the only way I could work out so far that can "predict" how much a function will be accelerated when run under Psyco. This is a very precious indication for an automatic Psyco-binder. The following table shows the results with the various test functions of the distribution's "test.py" file: (fn name) (speed-up) (bytecode insns per second) f1 106.00 2310545 f4 11.33 2819100 f5 12.08 2992445 f6 1.35 412022 f7 2.24 1331353 f7bis 10.29 1632296 The third column is '(tick_counter * check_interval) / execution_time'. The correlation between the two columns is admittedly not perfect, but still we can see that it was not worthy to try and accelerate f6 because it didn't spend a lot of time actually interpreting bytecodes. Note that similar information could be obtained by setting a line-tracing hook, counting not instructions but lines (which is less precise but still a good approximation). However, line tracing is *much* too slow for anything but debugging usage. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-04 10:42 Message: Logged In: YES user_id=6656 I see no harm in this. Are you sure it's actually going to be useful, though? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617311&group_id=5470 From noreply@sourceforge.net Mon Oct 7 10:48:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 02:48:53 -0700 Subject: [Patches] [ python-Patches-617309 ] getframe hook (Psyco #1) Message-ID: Patches item #617309, was opened at 2002-10-01 23:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617309&group_id=5470 Category: Core (C code) Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Guido van Rossum (gvanrossum) Summary: getframe hook (Psyco #1) Initial Comment: Psyco-friendly patch #1 Allow Psyco-like extension modules to quickly plug their own notion of frame call stack into Python, for the use of the interpreter's parts that rely on the call stack for context information. For example, the code that creates a new class implicitely reads the top frame's globals if the class does not explicitely defines a __module__ attribute. With this new hook, Psyco can provide such code with the expected frame object. pystate.h: The PyThreadState structure has a new field added at its end: Py_getframehook getframe; where typedef PyFrameObject *(*Py_getframehook)(PyThreadState *, int); This field points to a function that returns the nth frame object in the call stack. By default, it points to a standard function that starts with tstate->frame and walks their f_back fields, just like the implementation of sys._getframe(). The purpose of this is to allow Psyco to hook another function at this point, in order to lazily emulate the frame objects that correspond to frames executed by Psyco. sysmodule.c: sys_getframe() calls the hook. ceval.c: PyEval_GetFrame() calls the hook. various other places in ceval.c: replaced PyThreadState_Get()->frame with PyEval_GetFrame() so that the hook will be called. pyexpat.c: replaced a PyThreadState_Get()->frame->f_globals with PyEval_GetGlobals(). Note that there are other places using 'frame' and the 'f_back' pointers which have not been changed because they are concerned with actual (classical) bytecode interpretation. The hook is only used in places that are interested in obtaining contextual information (like what the previous frame's globals are), not in places that actually builds frames in which bytecode will be interpreted. Compatibility: third-party extension modules directly reading frame, like Expat before this patch, will exhibit a marginally wrong behavior with Psyco until they are modified to call the hook (or better the "official" interpreter routines that are modified to so do). It does not break anything at all as long as we are not using Psyco. Performance overhead: one more indirect call isn't heavy. More importantly, I don't expect the concerned functions to be used more than occasionally in any code. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-10-07 09:48 Message: Logged In: YES user_id=6656 OK, checked in as: Include/pystate.h revision 2.18.16.2 Modules/pyexpat.c revision 2.57.6.4 Python/ceval.c revision 2.301.4.8 Python/pystate.c revision 2.20.16.1 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-06 20:46 Message: Logged In: YES user_id=6380 I'd like to get this int. 2.2.2. MWH, can you check it in? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-04 15:46 Message: Logged In: YES user_id=4771 Here is a simpler patch doing only the one thing that I really cannot work around in Psyco (and I've tried, believe me!) : a way to hook my own replacement function for PyEval_GetFrame(). No more sysmodule change. Just a few places here and there with 'PyThreadState_Get()->frame' replaced with 'PyEval_GetFrame()' so that my hook will trigger. Is the new patch clean enough ? If so I'll assign it to Guido for review. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-04 10:43 Message: Logged In: YES user_id=6656 I'd be uneasy about a change of this subtlety going into the 2.2 branch. Aren't there other ways you can do this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617309&group_id=5470 From noreply@sourceforge.net Mon Oct 7 11:14:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 03:14:29 -0700 Subject: [Patches] [ python-Patches-619614 ] fixes for Lib/compiler for 2.2.2 Message-ID: Patches item #619614, was opened at 2002-10-07 10:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619614&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 8 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: fixes for Lib/compiler for 2.2.2 Initial Comment: Here's a few fixes for the Lib/compiler package on the release22-maint side. With them, I can compile Lib/*.py, Lib/test/test_*.py and run the test suite succesfully and without I can't, so I'm fairly sure I've improved the situation, but I'd still like a review. I'd really like something to be done about this before 2.2.2b1... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619614&group_id=5470 From noreply@sourceforge.net Mon Oct 7 12:26:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 04:26:58 -0700 Subject: [Patches] [ python-Patches-609700 ] always build with same $(CC) on Linux Message-ID: Patches item #609700, was opened at 2002-09-15 22:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=609700&group_id=5470 Category: Build Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 7 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: always build with same $(CC) on Linux Initial Comment: When configuring python with --with-gcc and/or --with- cxx, the shared modules are not built with the configured compilers and not linked with the configured compilers. The patch attached uses the configured compiler when building the shared modules. Python fails to build, when configured --with-gcc=gcc-3.2 on ia64-linux. Distilled code (thanks to Martin v. Loewis): #include int main(int argc, char*argv[]) { printf("%d\n", 16/argc); } Translate with: gcc-3.2 -c div.c gcc-2.95 -o div div.o call: ./div onearg prints 7, not 8. Should be fixed in 2.1 and 2.2 as well and maybe for other architectures. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-10-07 11:26 Message: Logged In: YES user_id=6656 I'm a little confused. How did your patch differ from doko's? Should this go into 2.2.2? Has it already? (Don't think so, but...) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-16 17:52 Message: Logged In: YES user_id=21627 Your patch was incorrect: it breaks if CC is not set in the environment. I committed a modified patch as configure.in 1.345 and configure 1.334. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=609700&group_id=5470 From noreply@sourceforge.net Mon Oct 7 12:36:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 04:36:13 -0700 Subject: [Patches] [ python-Patches-619614 ] fixes for Lib/compiler for 2.2.2 Message-ID: Patches item #619614, was opened at 2002-10-07 12:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619614&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 8 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: fixes for Lib/compiler for 2.2.2 Initial Comment: Here's a few fixes for the Lib/compiler package on the release22-maint side. With them, I can compile Lib/*.py, Lib/test/test_*.py and run the test suite succesfully and without I can't, so I'm fairly sure I've improved the situation, but I'd still like a review. I'd really like something to be done about this before 2.2.2b1... ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 13:36 Message: Logged In: YES user_id=21627 While the changes look all correct to me, I don't understand the rationale for moving the class.__doc__ snippet. It looks like this change has no effect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619614&group_id=5470 From noreply@sourceforge.net Mon Oct 7 12:41:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 04:41:29 -0700 Subject: [Patches] [ python-Patches-619614 ] fixes for Lib/compiler for 2.2.2 Message-ID: Patches item #619614, was opened at 2002-10-07 10:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619614&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 8 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: fixes for Lib/compiler for 2.2.2 Initial Comment: Here's a few fixes for the Lib/compiler package on the release22-maint side. With them, I can compile Lib/*.py, Lib/test/test_*.py and run the test suite succesfully and without I can't, so I'm fairly sure I've improved the situation, but I'd still like a review. I'd really like something to be done about this before 2.2.2b1... ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-10-07 11:41 Message: Logged In: YES user_id=6656 No, they do have an effect: without them, the class's docstring gets added to the enclosing scope! [mwh@pc150 build-ucs2-debug]$ cat c.py 'Module docstring' class C: 'class docstring' $ ./python ../Lib/compiler/pycodegen.py c.py $ ./python ... >>> import c >>> c.__doc__ 'class docstring' >>> c.C.__doc__ >>> One could change the node.emit()... stuff to gen.emit()... stuff and take the code out of the __init__ method, but it doesn't seem to make much difference to me. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 11:36 Message: Logged In: YES user_id=21627 While the changes look all correct to me, I don't understand the rationale for moving the class.__doc__ snippet. It looks like this change has no effect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619614&group_id=5470 From noreply@sourceforge.net Mon Oct 7 12:43:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 04:43:44 -0700 Subject: [Patches] [ python-Patches-614770 ] MSVC 7.0 compiler support Message-ID: Patches item #614770, was opened at 2002-09-26 05:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614770&group_id=5470 Category: Distutils and setup.py Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: John Anderson (djohnanderson) Assigned to: Nobody/Anonymous (nobody) Summary: MSVC 7.0 compiler support Initial Comment: Distutils doesn't work with the current shipping version of the Microsoft compiler (7.0). I've got a patch that fixes it (context diffs of msvccompiler.py against the latest code in CVS). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 13:43 Message: Logged In: YES user_id=21627 Can you report whether this patch works with MSVC 5? ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-09-26 23:38 Message: Logged In: YES user_id=618290 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-09-26 23:38 Message: Logged In: YES user_id=618290 Opps, I guess I forgot to check that little box. Sorry about that. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 06:30 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614770&group_id=5470 From noreply@sourceforge.net Mon Oct 7 12:57:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 04:57:51 -0700 Subject: [Patches] [ python-Patches-609700 ] always build with same $(CC) on Linux Message-ID: Patches item #609700, was opened at 2002-09-16 00:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=609700&group_id=5470 Category: Build Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 7 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: always build with same $(CC) on Linux Initial Comment: When configuring python with --with-gcc and/or --with- cxx, the shared modules are not built with the configured compilers and not linked with the configured compilers. The patch attached uses the configured compiler when building the shared modules. Python fails to build, when configured --with-gcc=gcc-3.2 on ia64-linux. Distilled code (thanks to Martin v. Loewis): #include int main(int argc, char*argv[]) { printf("%d\n", 16/argc); } Translate with: gcc-3.2 -c div.c gcc-2.95 -o div div.o call: ./div onearg prints 7, not 8. Should be fixed in 2.1 and 2.2 as well and maybe for other architectures. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 13:57 Message: Logged In: YES user_id=21627 The difference is in quoting: "$(CC) -shared" evaluates CC at configure time; '$(CC) -shared' puts this string literally into the makefile, so that CC is evaluated at make time. At configure time, CC might not be set, in the Makefile, it always is. I have now backported the change as configure.in 1.288.6.15; configure 1.279.6.15 (omitting the Hurd case). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-07 13:26 Message: Logged In: YES user_id=6656 I'm a little confused. How did your patch differ from doko's? Should this go into 2.2.2? Has it already? (Don't think so, but...) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-16 19:52 Message: Logged In: YES user_id=21627 Your patch was incorrect: it breaks if CC is not set in the environment. I committed a modified patch as configure.in 1.345 and configure 1.334. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=609700&group_id=5470 From noreply@sourceforge.net Mon Oct 7 13:02:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 05:02:40 -0700 Subject: [Patches] [ python-Patches-619614 ] fixes for Lib/compiler for 2.2.2 Message-ID: Patches item #619614, was opened at 2002-10-07 12:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619614&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open >Resolution: Accepted Priority: 8 Submitted By: Michael Hudson (mwh) >Assigned to: Michael Hudson (mwh) Summary: fixes for Lib/compiler for 2.2.2 Initial Comment: Here's a few fixes for the Lib/compiler package on the release22-maint side. With them, I can compile Lib/*.py, Lib/test/test_*.py and run the test suite succesfully and without I can't, so I'm fairly sure I've improved the situation, but I'd still like a review. I'd really like something to be done about this before 2.2.2b1... ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 14:02 Message: Logged In: YES user_id=21627 I see. The patch looks fine to me, then; please apply it. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-07 13:41 Message: Logged In: YES user_id=6656 No, they do have an effect: without them, the class's docstring gets added to the enclosing scope! [mwh@pc150 build-ucs2-debug]$ cat c.py 'Module docstring' class C: 'class docstring' $ ./python ../Lib/compiler/pycodegen.py c.py $ ./python ... >>> import c >>> c.__doc__ 'class docstring' >>> c.C.__doc__ >>> One could change the node.emit()... stuff to gen.emit()... stuff and take the code out of the __init__ method, but it doesn't seem to make much difference to me. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 13:36 Message: Logged In: YES user_id=21627 While the changes look all correct to me, I don't understand the rationale for moving the class.__doc__ snippet. It looks like this change has no effect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619614&group_id=5470 From noreply@sourceforge.net Mon Oct 7 13:23:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 05:23:17 -0700 Subject: [Patches] [ python-Patches-619614 ] fixes for Lib/compiler for 2.2.2 Message-ID: Patches item #619614, was opened at 2002-10-07 10:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619614&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: Accepted Priority: 8 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: fixes for Lib/compiler for 2.2.2 Initial Comment: Here's a few fixes for the Lib/compiler package on the release22-maint side. With them, I can compile Lib/*.py, Lib/test/test_*.py and run the test suite succesfully and without I can't, so I'm fairly sure I've improved the situation, but I'd still like a review. I'd really like something to be done about this before 2.2.2b1... ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-10-07 12:23 Message: Logged In: YES user_id=6656 Checked in as: Lib/compiler/pycodegen.py revision 1.58.4.2.2.1 Lib/compiler/symbols.py revision 1.10.8.1.2.1 Thanks for the review! (+ for #609700) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 12:02 Message: Logged In: YES user_id=21627 I see. The patch looks fine to me, then; please apply it. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-07 11:41 Message: Logged In: YES user_id=6656 No, they do have an effect: without them, the class's docstring gets added to the enclosing scope! [mwh@pc150 build-ucs2-debug]$ cat c.py 'Module docstring' class C: 'class docstring' $ ./python ../Lib/compiler/pycodegen.py c.py $ ./python ... >>> import c >>> c.__doc__ 'class docstring' >>> c.C.__doc__ >>> One could change the node.emit()... stuff to gen.emit()... stuff and take the code out of the __init__ method, but it doesn't seem to make much difference to me. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 11:36 Message: Logged In: YES user_id=21627 While the changes look all correct to me, I don't understand the rationale for moving the class.__doc__ snippet. It looks like this change has no effect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619614&group_id=5470 From noreply@sourceforge.net Mon Oct 7 13:23:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 05:23:31 -0700 Subject: [Patches] [ python-Patches-619614 ] fixes for Lib/compiler for 2.2.2 Message-ID: Patches item #619614, was opened at 2002-10-07 10:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619614&group_id=5470 Category: Library (Lib) Group: Python 2.2.x >Status: Closed Resolution: Accepted Priority: 8 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: fixes for Lib/compiler for 2.2.2 Initial Comment: Here's a few fixes for the Lib/compiler package on the release22-maint side. With them, I can compile Lib/*.py, Lib/test/test_*.py and run the test suite succesfully and without I can't, so I'm fairly sure I've improved the situation, but I'd still like a review. I'd really like something to be done about this before 2.2.2b1... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-07 12:23 Message: Logged In: YES user_id=6656 Checked in as: Lib/compiler/pycodegen.py revision 1.58.4.2.2.1 Lib/compiler/symbols.py revision 1.10.8.1.2.1 Thanks for the review! (+ for #609700) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 12:02 Message: Logged In: YES user_id=21627 I see. The patch looks fine to me, then; please apply it. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-07 11:41 Message: Logged In: YES user_id=6656 No, they do have an effect: without them, the class's docstring gets added to the enclosing scope! [mwh@pc150 build-ucs2-debug]$ cat c.py 'Module docstring' class C: 'class docstring' $ ./python ../Lib/compiler/pycodegen.py c.py $ ./python ... >>> import c >>> c.__doc__ 'class docstring' >>> c.C.__doc__ >>> One could change the node.emit()... stuff to gen.emit()... stuff and take the code out of the __init__ method, but it doesn't seem to make much difference to me. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 11:36 Message: Logged In: YES user_id=21627 While the changes look all correct to me, I don't understand the rationale for moving the class.__doc__ snippet. It looks like this change has no effect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619614&group_id=5470 From noreply@sourceforge.net Mon Oct 7 13:34:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 05:34:54 -0700 Subject: [Patches] [ python-Patches-617309 ] getframe hook (Psyco #1) Message-ID: Patches item #617309, was opened at 2002-10-01 19:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617309&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Closed Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Guido van Rossum (gvanrossum) Summary: getframe hook (Psyco #1) Initial Comment: Psyco-friendly patch #1 Allow Psyco-like extension modules to quickly plug their own notion of frame call stack into Python, for the use of the interpreter's parts that rely on the call stack for context information. For example, the code that creates a new class implicitely reads the top frame's globals if the class does not explicitely defines a __module__ attribute. With this new hook, Psyco can provide such code with the expected frame object. pystate.h: The PyThreadState structure has a new field added at its end: Py_getframehook getframe; where typedef PyFrameObject *(*Py_getframehook)(PyThreadState *, int); This field points to a function that returns the nth frame object in the call stack. By default, it points to a standard function that starts with tstate->frame and walks their f_back fields, just like the implementation of sys._getframe(). The purpose of this is to allow Psyco to hook another function at this point, in order to lazily emulate the frame objects that correspond to frames executed by Psyco. sysmodule.c: sys_getframe() calls the hook. ceval.c: PyEval_GetFrame() calls the hook. various other places in ceval.c: replaced PyThreadState_Get()->frame with PyEval_GetFrame() so that the hook will be called. pyexpat.c: replaced a PyThreadState_Get()->frame->f_globals with PyEval_GetGlobals(). Note that there are other places using 'frame' and the 'f_back' pointers which have not been changed because they are concerned with actual (classical) bytecode interpretation. The hook is only used in places that are interested in obtaining contextual information (like what the previous frame's globals are), not in places that actually builds frames in which bytecode will be interpreted. Compatibility: third-party extension modules directly reading frame, like Expat before this patch, will exhibit a marginally wrong behavior with Psyco until they are modified to call the hook (or better the "official" interpreter routines that are modified to so do). It does not break anything at all as long as we are not using Psyco. Performance overhead: one more indirect call isn't heavy. More importantly, I don't expect the concerned functions to be used more than occasionally in any code. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-07 08:34 Message: Logged In: YES user_id=6380 Thanks much Michael for the three sets of Psyco checkins in 2.2.2! Armin, I think for Python 2.3 some patches must be different because there's no SET_LINENO opcode. Can you provide updated versions for those? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-07 05:48 Message: Logged In: YES user_id=6656 OK, checked in as: Include/pystate.h revision 2.18.16.2 Modules/pyexpat.c revision 2.57.6.4 Python/ceval.c revision 2.301.4.8 Python/pystate.c revision 2.20.16.1 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-06 16:46 Message: Logged In: YES user_id=6380 I'd like to get this int. 2.2.2. MWH, can you check it in? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-04 11:46 Message: Logged In: YES user_id=4771 Here is a simpler patch doing only the one thing that I really cannot work around in Psyco (and I've tried, believe me!) : a way to hook my own replacement function for PyEval_GetFrame(). No more sysmodule change. Just a few places here and there with 'PyThreadState_Get()->frame' replaced with 'PyEval_GetFrame()' so that my hook will trigger. Is the new patch clean enough ? If so I'll assign it to Guido for review. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-04 06:43 Message: Logged In: YES user_id=6656 I'd be uneasy about a change of this subtlety going into the 2.2 branch. Aren't there other ways you can do this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617309&group_id=5470 From noreply@sourceforge.net Mon Oct 7 14:24:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 06:24:33 -0700 Subject: [Patches] [ python-Patches-448038 ] a move function for shutil.py Message-ID: Patches item #448038, was opened at 2001-08-05 02:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=448038&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: William McVey (wamcvey) Assigned to: Nobody/Anonymous (nobody) Summary: a move function for shutil.py Initial Comment: Although shutil.py has some nice copy functions but no real equivalent of mv(1). This is a very simple implimentation (as in not a whole lot of stuff has been implimented) but it's functional. Simply calls rename, and if that fails tries to copy and unlink. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 15:24 Message: Logged In: YES user_id=21627 Committed as shutil.py 1.24, libshutil.tex 1.11, NEWS 1.494. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-03-09 12:24 Message: Logged In: YES user_id=21627 Here is an attempt to provide error handling for copytree. It collects all exceptions in a list, and raises them as shutil.Error. This would be inconsistent with shutil.rmtree, which offers the choice of ignore errors,invoke an error callback, or raise an exception at the problem. Which of these alternatives would you like to see implemented? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 17:41 Message: Logged In: YES user_id=6380 This is OK, but only perpetuates the problem with this module -- it doesn't have a decent error handling strategy (prints to stdout!?!?!?!). If someone wants to put some more effort in this, I would recommend at least adding an option to copytree() to control error handling. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=448038&group_id=5470 From noreply@sourceforge.net Mon Oct 7 14:25:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 06:25:50 -0700 Subject: [Patches] [ python-Patches-458898 ] --python-build for install Message-ID: Patches item #458898, was opened at 2001-09-05 22:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=458898&group_id=5470 Category: Distutils and setup.py Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Michael Hudson (mwh) Summary: --python-build for install Initial Comment: Sometimes, being able to install python tools without having python installed is desirable. When building an RPM package of python, for example, one may want to build/install IDLE as well, including it in a subpackage. Indeed, we're doing this with a couple of python tools here at Conectiva. Unfortunately, we have a egg-chicken problem when doing this. You need python installed in your system before you install tools. This limitation may be observed in the file Lib/distutils/sysconfig.py. It looks for Makefile in the final installation directory, for example. This patch adds a new option to dist-utils' install command: --python-build. When used, python will look for these files in the python build directory specified trough the option. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 15:25 Message: Logged In: YES user_id=21627 Rejecting the patch since there was no response. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-28 13:07 Message: Logged In: YES user_id=21627 It appears that the patch is outdated; set_python_build is no longer. Is the patch still needed? ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-01-31 15:18 Message: Logged In: YES user_id=7887 About.. 1) Sorry.. I'll take care to add comments to the file next time. The bottom one is newer. 2) For now, a local option seems to be ok. If other commands start using it (what seems unprobable right now), we may turn it into a global option without any drawbacks, since global options are acceptable anywhere. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-21 11:45 Message: Logged In: YES user_id=6656 Ta. Some random comments: (1) it's not obvious from this page which of the two patches attached is the newer. This may be sf's fault, but... (2) might it be better to make this a global distutils option? It seems a bit fragile at the moment -- we'd need to change things if, say, build_ext started to depend on python_build. Would, say $ python setup.py --python-build install be better? I dunno, I don't really understand how options chase around distutils yet... ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-01-19 01:02 Message: Logged In: YES user_id=7887 Here is a new patch including your suggestions. Thank you!! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-17 18:49 Message: Logged In: YES user_id=6656 Hey! This patch is less than six months old. Virtually fresh :| Some comments: are you sure you can get away with only honouring --python-build in install? I think build_scripts needs it too (now, anyway, maybe not when you wrote the patch). Also, the mod to install.finalize_options() is in the wrong place wrt. the surrouding comments. Can you fix this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=458898&group_id=5470 From noreply@sourceforge.net Mon Oct 7 14:58:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 06:58:10 -0700 Subject: [Patches] [ python-Patches-479898 ] Multibyte string on string::string_print Message-ID: Patches item #479898, was opened at 2001-11-09 08:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=479898&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Multibyte string on string::string_print Initial Comment: Many multibyte language users are difficult to see native characters on list or dictionary and etc. This patch allows printing multibyte on UNIX98- compatible machines; mbtowc() is ISO/IEC 9899:1990 standard C-API function. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 15:58 Message: Logged In: YES user_id=21627 Thanks for the patch, committed as configure 1.343; configure.in 1.354; pyconfig.h.in 1.51; stringobject.c 2.190; I'm not quite sure that your correction is correct: If we invoke iswprint, cr is already guaranteed to be >0, since we otherwise goto nonprintable. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-10 04:38 Message: Logged In: YES user_id=55188 Oops, one mistake. sorry. stringobject.c:646 else if (_ISPRINT(c)) { -> else if (cr > 0 && _ISPRINT(c)) { (to detect whether mbtowc failed to convert) ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-10 04:26 Message: Logged In: YES user_id=55188 I uploaded 2nd patches which contains configure support. Unfortunately, Citrus(new generation locale support for *BSDs) didn't implemented iswprint() yet. but *BSDs supports wide character via Rune Locale isprint() func. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 14:21 Message: Logged In: YES user_id=6380 Still, the patch as it exists is unacceptable -- it needs configure support to decide whether to use mbtowc() and whether to use iswprint() or isprint() (I would hope on BSD there is also an iswprint(), to be standard-conforming). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-07 07:38 Message: Logged In: YES user_id=55188 Yes, it should be changed to iswprint on Linux systems. (but, isprint of BSD systems was designed for wide characters) As loewis told, EUC codes of Korea, Japan, Taiwan doesn't use 0x7F-0x9F for printable character. So, I think that using mbtowc is unavoidable. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-06 16:12 Message: Logged In: YES user_id=21627 You are right, the code should use iswprint instead. The point is that multiple subsequent bytes can make up a single printable character. Not every character above 127 is necessarily printable (e.g. in Latin-1, only characters above 160 are printable). Likewise, a single byte may not be printable, but a combination will print fine. So this code is supposed to catch only those cases where printing will actually work. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 20:08 Message: Logged In: YES user_id=6380 I don't understand the point of using mbtowc() here. The code extracts a wide character, but then it uses isprint() on it, and as far as I know, isprint() is not defined on wide characters, only on 'unsigned char' (and on -1). Isn't what the author wants simply to is isprint(c) instead of (c < ' ' || c >= 0x7f)??? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-09 22:21 Message: Logged In: YES user_id=21627 Even though I think this patch is correct in principle, I see a few problems with it: 1. Since it doesn't fix a bug, it probably cannot go into 2.2. 2. There is no autoconf test for mbtowc. You should test this in configure, and then conditionalize your code on HAVE_MBTOWC. 3. There is too much code duplication. Try to find a solution which special-cases the escape codes (\something) only once. For example, you may implement a trivial mbtowc redefinition if mbtowc is not available, and then use mbtowc always. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=479898&group_id=5470 From noreply@sourceforge.net Mon Oct 7 15:17:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 07:17:13 -0700 Subject: [Patches] [ python-Patches-617311 ] Tiny profiling info (Psyco #2) Message-ID: Patches item #617311, was opened at 2002-10-01 23:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617311&group_id=5470 Category: Core (C code) >Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) >Assigned to: Michael Hudson (mwh) Summary: Tiny profiling info (Psyco #2) Initial Comment: Psyco-friendly patch #2. A very very small statistic-collecting patch. pystate.h: added a field at the end of the PyThreadStruct: int tick_counter; ceval.c: eval_frame(): tstate->tick_counter is incremented whenever the check_interval ticker reaches zero. The purpose is to give a useful measure of the number of interpreted bytecode instructions in a given thread. This extremely lightweight statistic collector can be of interest to profilers (like psyco.jit()). We can safely guess that a single integer increment every 100 interpreted bytecode instructions will go entierely unnoticed in any performance measure. [This is true for pystone.py.] ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2002-10-07 14:17 Message: Logged In: YES user_id=4771 Uploaded the 2.3 patch (this one cleanly generated -- for the other one I just cat'ed two patches in one). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-07 09:42 Message: Logged In: YES user_id=6656 Done in Include/pystate.h revision 2.18.16.1 Python/ceval.c revision 2.301.4.7 Armin, I don't know how you generated this patch, but it would have been easier to apply if it had been rooted in the "src" directory, like e.g.: $ cvs diff Include/pystate.h Python/ceval.c > ~/diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-06 20:45 Message: Logged In: YES user_id=6380 I'd like to get this into 2.2.2. MWH, can you check it in? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-04 14:36 Message: Logged In: YES user_id=4771 It is the only way I could work out so far that can "predict" how much a function will be accelerated when run under Psyco. This is a very precious indication for an automatic Psyco-binder. The following table shows the results with the various test functions of the distribution's "test.py" file: (fn name) (speed-up) (bytecode insns per second) f1 106.00 2310545 f4 11.33 2819100 f5 12.08 2992445 f6 1.35 412022 f7 2.24 1331353 f7bis 10.29 1632296 The third column is '(tick_counter * check_interval) / execution_time'. The correlation between the two columns is admittedly not perfect, but still we can see that it was not worthy to try and accelerate f6 because it didn't spend a lot of time actually interpreting bytecodes. Note that similar information could be obtained by setting a line-tracing hook, counting not instructions but lines (which is less precise but still a good approximation). However, line tracing is *much* too slow for anything but debugging usage. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-04 10:42 Message: Logged In: YES user_id=6656 I see no harm in this. Are you sure it's actually going to be useful, though? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617311&group_id=5470 From noreply@sourceforge.net Mon Oct 7 15:31:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 07:31:59 -0700 Subject: [Patches] [ python-Patches-617309 ] getframe hook (Psyco #1) Message-ID: Patches item #617309, was opened at 2002-10-01 23:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617309&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Closed Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Guido van Rossum (gvanrossum) Summary: getframe hook (Psyco #1) Initial Comment: Psyco-friendly patch #1 Allow Psyco-like extension modules to quickly plug their own notion of frame call stack into Python, for the use of the interpreter's parts that rely on the call stack for context information. For example, the code that creates a new class implicitely reads the top frame's globals if the class does not explicitely defines a __module__ attribute. With this new hook, Psyco can provide such code with the expected frame object. pystate.h: The PyThreadState structure has a new field added at its end: Py_getframehook getframe; where typedef PyFrameObject *(*Py_getframehook)(PyThreadState *, int); This field points to a function that returns the nth frame object in the call stack. By default, it points to a standard function that starts with tstate->frame and walks their f_back fields, just like the implementation of sys._getframe(). The purpose of this is to allow Psyco to hook another function at this point, in order to lazily emulate the frame objects that correspond to frames executed by Psyco. sysmodule.c: sys_getframe() calls the hook. ceval.c: PyEval_GetFrame() calls the hook. various other places in ceval.c: replaced PyThreadState_Get()->frame with PyEval_GetFrame() so that the hook will be called. pyexpat.c: replaced a PyThreadState_Get()->frame->f_globals with PyEval_GetGlobals(). Note that there are other places using 'frame' and the 'f_back' pointers which have not been changed because they are concerned with actual (classical) bytecode interpretation. The hook is only used in places that are interested in obtaining contextual information (like what the previous frame's globals are), not in places that actually builds frames in which bytecode will be interpreted. Compatibility: third-party extension modules directly reading frame, like Expat before this patch, will exhibit a marginally wrong behavior with Psyco until they are modified to call the hook (or better the "official" interpreter routines that are modified to so do). It does not break anything at all as long as we are not using Psyco. Performance overhead: one more indirect call isn't heavy. More importantly, I don't expect the concerned functions to be used more than occasionally in any code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-07 12:34 Message: Logged In: YES user_id=6380 Thanks much Michael for the three sets of Psyco checkins in 2.2.2! Armin, I think for Python 2.3 some patches must be different because there's no SET_LINENO opcode. Can you provide updated versions for those? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-07 09:48 Message: Logged In: YES user_id=6656 OK, checked in as: Include/pystate.h revision 2.18.16.2 Modules/pyexpat.c revision 2.57.6.4 Python/ceval.c revision 2.301.4.8 Python/pystate.c revision 2.20.16.1 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-06 20:46 Message: Logged In: YES user_id=6380 I'd like to get this int. 2.2.2. MWH, can you check it in? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-04 15:46 Message: Logged In: YES user_id=4771 Here is a simpler patch doing only the one thing that I really cannot work around in Psyco (and I've tried, believe me!) : a way to hook my own replacement function for PyEval_GetFrame(). No more sysmodule change. Just a few places here and there with 'PyThreadState_Get()->frame' replaced with 'PyEval_GetFrame()' so that my hook will trigger. Is the new patch clean enough ? If so I'll assign it to Guido for review. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-04 10:43 Message: Logged In: YES user_id=6656 I'd be uneasy about a change of this subtlety going into the 2.2 branch. Aren't there other ways you can do this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617309&group_id=5470 From noreply@sourceforge.net Mon Oct 7 15:32:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 07:32:49 -0700 Subject: [Patches] [ python-Patches-617309 ] getframe hook (Psyco #1) Message-ID: Patches item #617309, was opened at 2002-10-01 23:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617309&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Closed Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) >Assigned to: Michael Hudson (mwh) Summary: getframe hook (Psyco #1) Initial Comment: Psyco-friendly patch #1 Allow Psyco-like extension modules to quickly plug their own notion of frame call stack into Python, for the use of the interpreter's parts that rely on the call stack for context information. For example, the code that creates a new class implicitely reads the top frame's globals if the class does not explicitely defines a __module__ attribute. With this new hook, Psyco can provide such code with the expected frame object. pystate.h: The PyThreadState structure has a new field added at its end: Py_getframehook getframe; where typedef PyFrameObject *(*Py_getframehook)(PyThreadState *, int); This field points to a function that returns the nth frame object in the call stack. By default, it points to a standard function that starts with tstate->frame and walks their f_back fields, just like the implementation of sys._getframe(). The purpose of this is to allow Psyco to hook another function at this point, in order to lazily emulate the frame objects that correspond to frames executed by Psyco. sysmodule.c: sys_getframe() calls the hook. ceval.c: PyEval_GetFrame() calls the hook. various other places in ceval.c: replaced PyThreadState_Get()->frame with PyEval_GetFrame() so that the hook will be called. pyexpat.c: replaced a PyThreadState_Get()->frame->f_globals with PyEval_GetGlobals(). Note that there are other places using 'frame' and the 'f_back' pointers which have not been changed because they are concerned with actual (classical) bytecode interpretation. The hook is only used in places that are interested in obtaining contextual information (like what the previous frame's globals are), not in places that actually builds frames in which bytecode will be interpreted. Compatibility: third-party extension modules directly reading frame, like Expat before this patch, will exhibit a marginally wrong behavior with Psyco until they are modified to call the hook (or better the "official" interpreter routines that are modified to so do). It does not break anything at all as long as we are not using Psyco. Performance overhead: one more indirect call isn't heavy. More importantly, I don't expect the concerned functions to be used more than occasionally in any code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-07 12:34 Message: Logged In: YES user_id=6380 Thanks much Michael for the three sets of Psyco checkins in 2.2.2! Armin, I think for Python 2.3 some patches must be different because there's no SET_LINENO opcode. Can you provide updated versions for those? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-07 09:48 Message: Logged In: YES user_id=6656 OK, checked in as: Include/pystate.h revision 2.18.16.2 Modules/pyexpat.c revision 2.57.6.4 Python/ceval.c revision 2.301.4.8 Python/pystate.c revision 2.20.16.1 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-06 20:46 Message: Logged In: YES user_id=6380 I'd like to get this int. 2.2.2. MWH, can you check it in? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-04 15:46 Message: Logged In: YES user_id=4771 Here is a simpler patch doing only the one thing that I really cannot work around in Psyco (and I've tried, believe me!) : a way to hook my own replacement function for PyEval_GetFrame(). No more sysmodule change. Just a few places here and there with 'PyThreadState_Get()->frame' replaced with 'PyEval_GetFrame()' so that my hook will trigger. Is the new patch clean enough ? If so I'll assign it to Guido for review. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-04 10:43 Message: Logged In: YES user_id=6656 I'd be uneasy about a change of this subtlety going into the 2.2 branch. Aren't there other ways you can do this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617309&group_id=5470 From noreply@sourceforge.net Mon Oct 7 16:27:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 08:27:50 -0700 Subject: [Patches] [ python-Patches-614770 ] MSVC 7.0 compiler support Message-ID: Patches item #614770, was opened at 2002-09-25 20:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614770&group_id=5470 Category: Distutils and setup.py Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: John Anderson (djohnanderson) Assigned to: Nobody/Anonymous (nobody) Summary: MSVC 7.0 compiler support Initial Comment: Distutils doesn't work with the current shipping version of the Microsoft compiler (7.0). I've got a patch that fixes it (context diffs of msvccompiler.py against the latest code in CVS). ---------------------------------------------------------------------- >Comment By: John Anderson (djohnanderson) Date: 2002-10-07 08:27 Message: Logged In: YES user_id=618290 It's been so long since I had a copy of MSVC 5 -- I think it became obsolete about 6 or 7 years ago. None of my changes should have any impact on the operation of MSVC 5, but of course you never know unless you try it. Also, the MSVC 6 support in distutils is currently broken -- although it finds the compiler, the code to find the include paths is totally broken. I have MSVC 6 (latest service pack) and 7 and would be willing to make both those work. Anyone who's using 5 is going to have lots of other problems to deal with besides distutils. Wouldn't surprise me if the MSVC 6 code for finding paths would differ in each service pack -- since it depends upon unsupported registry entries. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 04:43 Message: Logged In: YES user_id=21627 Can you report whether this patch works with MSVC 5? ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-09-26 14:38 Message: Logged In: YES user_id=618290 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-09-26 14:38 Message: Logged In: YES user_id=618290 Opps, I guess I forgot to check that little box. Sorry about that. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-25 21:30 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614770&group_id=5470 From noreply@sourceforge.net Mon Oct 7 16:29:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 08:29:11 -0700 Subject: [Patches] [ python-Patches-617309 ] getframe hook (Psyco #1) Message-ID: Patches item #617309, was opened at 2002-10-01 23:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617309&group_id=5470 Category: Core (C code) >Group: Python 2.3 >Status: Open Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Michael Hudson (mwh) Summary: getframe hook (Psyco #1) Initial Comment: Psyco-friendly patch #1 Allow Psyco-like extension modules to quickly plug their own notion of frame call stack into Python, for the use of the interpreter's parts that rely on the call stack for context information. For example, the code that creates a new class implicitely reads the top frame's globals if the class does not explicitely defines a __module__ attribute. With this new hook, Psyco can provide such code with the expected frame object. pystate.h: The PyThreadState structure has a new field added at its end: Py_getframehook getframe; where typedef PyFrameObject *(*Py_getframehook)(PyThreadState *, int); This field points to a function that returns the nth frame object in the call stack. By default, it points to a standard function that starts with tstate->frame and walks their f_back fields, just like the implementation of sys._getframe(). The purpose of this is to allow Psyco to hook another function at this point, in order to lazily emulate the frame objects that correspond to frames executed by Psyco. sysmodule.c: sys_getframe() calls the hook. ceval.c: PyEval_GetFrame() calls the hook. various other places in ceval.c: replaced PyThreadState_Get()->frame with PyEval_GetFrame() so that the hook will be called. pyexpat.c: replaced a PyThreadState_Get()->frame->f_globals with PyEval_GetGlobals(). Note that there are other places using 'frame' and the 'f_back' pointers which have not been changed because they are concerned with actual (classical) bytecode interpretation. The hook is only used in places that are interested in obtaining contextual information (like what the previous frame's globals are), not in places that actually builds frames in which bytecode will be interpreted. Compatibility: third-party extension modules directly reading frame, like Expat before this patch, will exhibit a marginally wrong behavior with Psyco until they are modified to call the hook (or better the "official" interpreter routines that are modified to so do). It does not break anything at all as long as we are not using Psyco. Performance overhead: one more indirect call isn't heavy. More importantly, I don't expect the concerned functions to be used more than occasionally in any code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-07 12:34 Message: Logged In: YES user_id=6380 Thanks much Michael for the three sets of Psyco checkins in 2.2.2! Armin, I think for Python 2.3 some patches must be different because there's no SET_LINENO opcode. Can you provide updated versions for those? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-07 09:48 Message: Logged In: YES user_id=6656 OK, checked in as: Include/pystate.h revision 2.18.16.2 Modules/pyexpat.c revision 2.57.6.4 Python/ceval.c revision 2.301.4.8 Python/pystate.c revision 2.20.16.1 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-06 20:46 Message: Logged In: YES user_id=6380 I'd like to get this int. 2.2.2. MWH, can you check it in? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-04 15:46 Message: Logged In: YES user_id=4771 Here is a simpler patch doing only the one thing that I really cannot work around in Psyco (and I've tried, believe me!) : a way to hook my own replacement function for PyEval_GetFrame(). No more sysmodule change. Just a few places here and there with 'PyThreadState_Get()->frame' replaced with 'PyEval_GetFrame()' so that my hook will trigger. Is the new patch clean enough ? If so I'll assign it to Guido for review. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-04 10:43 Message: Logged In: YES user_id=6656 I'd be uneasy about a change of this subtlety going into the 2.2 branch. Aren't there other ways you can do this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617309&group_id=5470 From noreply@sourceforge.net Mon Oct 7 16:29:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 08:29:39 -0700 Subject: [Patches] [ python-Patches-617311 ] Tiny profiling info (Psyco #2) Message-ID: Patches item #617311, was opened at 2002-10-01 23:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617311&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Open Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Michael Hudson (mwh) Summary: Tiny profiling info (Psyco #2) Initial Comment: Psyco-friendly patch #2. A very very small statistic-collecting patch. pystate.h: added a field at the end of the PyThreadStruct: int tick_counter; ceval.c: eval_frame(): tstate->tick_counter is incremented whenever the check_interval ticker reaches zero. The purpose is to give a useful measure of the number of interpreted bytecode instructions in a given thread. This extremely lightweight statistic collector can be of interest to profilers (like psyco.jit()). We can safely guess that a single integer increment every 100 interpreted bytecode instructions will go entierely unnoticed in any performance measure. [This is true for pystone.py.] ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-07 14:17 Message: Logged In: YES user_id=4771 Uploaded the 2.3 patch (this one cleanly generated -- for the other one I just cat'ed two patches in one). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-07 09:42 Message: Logged In: YES user_id=6656 Done in Include/pystate.h revision 2.18.16.1 Python/ceval.c revision 2.301.4.7 Armin, I don't know how you generated this patch, but it would have been easier to apply if it had been rooted in the "src" directory, like e.g.: $ cvs diff Include/pystate.h Python/ceval.c > ~/diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-06 20:45 Message: Logged In: YES user_id=6380 I'd like to get this into 2.2.2. MWH, can you check it in? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-04 14:36 Message: Logged In: YES user_id=4771 It is the only way I could work out so far that can "predict" how much a function will be accelerated when run under Psyco. This is a very precious indication for an automatic Psyco-binder. The following table shows the results with the various test functions of the distribution's "test.py" file: (fn name) (speed-up) (bytecode insns per second) f1 106.00 2310545 f4 11.33 2819100 f5 12.08 2992445 f6 1.35 412022 f7 2.24 1331353 f7bis 10.29 1632296 The third column is '(tick_counter * check_interval) / execution_time'. The correlation between the two columns is admittedly not perfect, but still we can see that it was not worthy to try and accelerate f6 because it didn't spend a lot of time actually interpreting bytecodes. Note that similar information could be obtained by setting a line-tracing hook, counting not instructions but lines (which is less precise but still a good approximation). However, line tracing is *much* too slow for anything but debugging usage. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-04 10:42 Message: Logged In: YES user_id=6656 I see no harm in this. Are you sure it's actually going to be useful, though? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617311&group_id=5470 From noreply@sourceforge.net Mon Oct 7 16:35:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 08:35:29 -0700 Subject: [Patches] [ python-Patches-617312 ] debugger-controlled jumps (Psyco #3) Message-ID: Patches item #617312, was opened at 2002-10-01 23:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617312&group_id=5470 Category: Core (C code) >Group: Python 2.3 >Status: Open Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) >Assigned to: Michael Hudson (mwh) Summary: debugger-controlled jumps (Psyco #3) Initial Comment: Psyco-friendly patch #3. Allows the C profile and trace functions (called upon function entry, line tracing, function exit, and exception) to alter some fields of the current PyFrameObject to influence the execution of the main loop. This is currently impossible because all the relevant fields are copied into local variables of eval_frame(), shadowing any subsequence change in the frame object. This is designed for what I plan to do with Psyco, but could also be used by advanced debuggers to allow the execution point to be modified by the user. Besides, the patch is just a matter of swapping a few lines in eval_frame(), introducing almost no extra complexity. In ceval.c:eval_frame(): The calls to call_trace(...PyTrace_CALL...) at the beginning of the code have been moved above the initialization of the local variables, allowing the trace functions to fiddle with the frame object before the main loop sees it. There is also a bug fix here: if the profile or trace functions raise an error at this point, eval_frame() used to quit without restoring tstate->frame and tstate->recursion_depth. [XXX should have been a bug report on its own] Finally, the call_trace() on SET_LINENO has been slightly modified to allow the trace function to move the execution point elsewhere. This is done by saving a few local variables are saved to and restored from the frame object around the call_trace(). The variables are the current instruction pointer (which was already saved in f->f_lasti, but is now restored from f->f_lasti too), and the current stack_pointer. Compatibility: f->f_stacktop normally remains NULL for the whole execution of the frame. This patch sets it to a non-NULL value for the duration of the call to the line-by-line trace function. I expect this not to cause any incompatibility because f->f_stacktop is not visible from Python code. I do not expect extension modules to rely on this detail. Note however that this has an influence on the GC, which only visits the stack if f->f_stacktop is set. Again, I assume this is not an issue -- it cannot even cause dead cycles to be detected earlier by the GC because as long as we are in the call_trace() call, we have a live reference to f. Performance: when tracing is on, SET_LINENO is now marginally slower. I guess this is not considered as an issue given the debugging nature of tracing. In Python 2.3, line tracing is currently *much* heavier and nobody seems to complain ;-) ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2002-10-07 15:35 Message: Logged In: YES user_id=4771 Uploaded patch for 2.3. I had to change the order of some things in the main loop -- namely, call maybe_call_trace_line () before the next opcode/oparg is loaded. To do so I had to simplify the signature of maybe_call_trace_line(): I removed its first argument, 'opcode', which wasn't used any more anyway. I carefully checked that I didn't broke anything, and 'test_trace' says so, but you may as well double-check the patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-07 09:38 Message: Logged In: YES user_id=6656 OK done, in ceval.c revision 2.301.4.6. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-07 00:28 Message: Logged In: YES user_id=4771 Here you are! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-06 20:44 Message: Logged In: YES user_id=6380 I'd like to get this into 2.2.2, but the patch doesn't apply cleanly (courtesy of MWH fixing the beg reported herein :-). Armin, can you upload a fixed patch? Or if MWH reads this, can you check this and the other two in? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-03 08:50 Message: Logged In: YES user_id=6656 Fair enough. Let's see what Guido thinks. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-02 20:33 Message: Logged In: YES user_id=4771 The trace function can change f_lasti if it knows what it does and if it accordingly changes all other fields too, like f_stacktop, f_blockstack and f_iblock. In fact, f_lasti and f_stacktop are the only fields of the frame objects that are currently cached in local variables (with the exception of what concerns the f_code object itself) so that this patch is enough to let the trace function actually move the execution point elsewhere. This would be quite useful in Psyco, if the rest of the function has been emulated and we then want the main loop to exit with the proper value: just move f_lasti just before the RETURN_VALUE opcode, clean up the stack and block stack, and push the already-computed result value where RETURN_VALUE will find it. Psyco could also execute just a part of the function and give it back to Python at some later position. A "clean hack". ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-02 13:14 Message: Logged In: YES user_id=6656 Never mind, the bug offended me so much that I fixed it both on the trunk and the 22-maint branch. Python/ceval.c revisions 2.337 and 2.301.4.5 Lib/test/test_trace.py revisions 1.4 and 1.4.2.1 (probably a 2.1 bugix candidate, if any cares...) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-02 12:23 Message: Logged In: YES user_id=6656 What about the blockstack? Are you just relying on trace functions not moving f_lasti unwisely? Agree about the bug. Do you have a test case for it? Otherwise I'll cook one up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617312&group_id=5470 From noreply@sourceforge.net Mon Oct 7 18:25:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 10:25:40 -0700 Subject: [Patches] [ python-Patches-617906 ] Build Error on Systems Without IPv6 Supp Message-ID: Patches item #617906, was opened at 2002-10-02 23:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617906&group_id=5470 Category: Build Group: Python 2.2.x Status: Closed Resolution: Rejected Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Nobody/Anonymous (nobody) Summary: Build Error on Systems Without IPv6 Supp Initial Comment: The problem was discovered installing 2.2.1 from the src.rpm on a Redhat 6.2 system which does not have IPv6 support. The 17 Sept 02 revision of python-2.2.spec (2.2.1-2) defaults to building Python with the configure switch --enable-ipv6=yes. An AC_ARG_ENABLE macro in configure.in sets ENABLE_IPV6 if the config switch is set, without checking whether the system has the resources to build and run IPv6. This forces a compile with IPV6 support which fails on my system. Python then ends up without any socket support since .../lib-dynload/_socket.so is missing. Among other problems, this AC_ARG_ENABLE logic re-exposes Bug 454493. For clarity, the patch is provided in three stages, meant to be applied in sequence: 1. configure.in.patch1 supplies the minimum to move the AF_INET6 and RFC2553 tests out of the ACTION_IF_NOT_GIVEN section of the macro. A default of no IPv6 support is supplied. 2. configure.in.patch2 integrates the stack type and IPv6 library presence tests into the logic which sets ENABLE_IPV6. Trace messages are added to the test for IPv6 library presence. The logic is changed so that the build will default to IPv4 instead of exiting the configuration process if the IPv6 library is not found. IPv6 support is compiled only if the system passes all the tests. Finally, some comments in the stack type check are changed to allow them to appear in configure as well as configure.in. 3. configure.in.patch3 does whitespace normalization for this section of configure.in. This patch may solve the problem raised in Bug 553000; I experienced shell errors testing the various paths through the stack type check / library check until I quoted the shell variables in the library check. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2002-10-07 12:25 Message: Logged In: YES user_id=149084 You have solved 90% of the problem with the change to the RPM .spec file. I don't see anything in my patch which ineeds to be considered for 2.2 at this point. You're the right person to review this, but the 2.2.2 release has a much higher priority than this patch. Thanks for your time. I'll send you some further comments later. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-04 16:14 Message: Logged In: YES user_id=21627 Unless you can demonstrate a real bug, I won't accept any patches for Python 2.2; this is for bug fixes only. For Python 2.3, there is an entirely different story. Patches are fine, if: - they are against the Python CVS - they are accompanied of a rationale explaining the problem they intend to fix, or the feature they intend to introduce, - are minimal in this respect: one patch at a time, which only solves the demonstrated problem, or only provides a single feature. For your proposed change: 1. I believe this is already the case; IPv6 *is* the default if nothing is specified, and an IPv6 library is detected. 2. I would not like such a change: there is always a chance that the C library will support the API nicely, but configure fails to foresee that it will work out. On such a system, users need a way to try out IPv6. I have real difficulties to understand your changes, and I don't want to guess for 2.2. If you are unhappy with that, we can certainly reopen this patch, so another reviewer can look at it. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-10-04 15:32 Message: Logged In: YES user_id=149084 Well, I'm disappointed that you are rejecting the patch completely. It does more than just tighten up the enable-ipv6 logic. Among other things, there are additional configure messages and I believe a bug in the library presence check code has been fixed. What would you say if I were to update it with the following changes? 1. Make configuring IPv6 the default when the switch is absent. 2. Exit from the configure script if --enable-ipv6=yes but the four tests don't all run successfully. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-04 01:39 Message: Logged In: YES user_id=21627 I see, so it fails because you have glibc 2.1. Then this is clearly an error in the spec file; there is no need to pass --enable-ipv6 on Linux. There are various other cases where configure exits, e.g. when computation of sizes of builtin types fails, or if relative paths are specified for --prefix etc. They are just less likely to happen. Sean Reifschneider will update the .spec file in this matter, so I'll reject the patch. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-10-03 15:58 Message: Logged In: YES user_id=149084 > Can you please elaborate on how precisely the build > fails on your system, and precisely what software you > are using (operating system, C library)? Linux float.attbi.com 2.2.5-15 RH 6.2(+) glibc-2.1.3-23 glibc-devel-2.1.3-23 [kbk@float ~]$ rpm -qi python2 Name : python2 Relocations: /usr Version : 2.2.1 Vendor: (none) Release : 2 Build Date: Sat Sep 28 01:11:35 2002 Install date: Sat Sep 28 01:41:58 2002 Build Host: float.attbi.com Group : Development/Languages Source RPM: python2-2.2.1-2.src.rpm Excerpt from the build log: ================== checking for usconfig in -lmpc... no checking for thr_create in -lthread... no checking if --enable-ipv6 is specified... yes checking ipv6 stack type... linux-glibc checking for --with-cycle-gc... yes checking for --with-pymalloc... no [...] building '_socket' extension /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c: In function `make\sockaddr': /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c:733: structure has\ no member named `sin6_scope_id' /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c: In function `gets\ockaddrarg': /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c:846: structure has\ no member named `sin6_scope_id' /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c: In function `PySo\cket_getnameinfo': /usr/local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c:2598: structure ha\s no member named `sin6_scope_id' gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DUSE_SSL=1 -I. -I/usr/loca\l/src/rpm/BUILD/Python-2.2.1/./Include -I/usr/local/include -IInclude/ -c /usr/\local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c -o build/temp.linux-i68\6-2.2/socketmodule.o WARNING: building of extension "_socket" failed: command 'gcc' failed with exit\ status 1 =================== ** Because the .spec sets the --enable-ipv6 the AF_INET6 and RFC2553 tests were skipped. _socket.so was not created, but the build continued with no socket support at all. ** If I run ./configure --enable-ipv6=no _socket.so is built as follows: ====================== building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DUSE_SSL=1 -I. -I/usr/loca\l/src/rpm/BUILD/Python-2.2.1/./Include -I/usr/local/include -IInclude/ -c /usr/\local/src/rpm/BUILD/Python-2.2.1/Modules/socketmodule.c -o build/temp.linux-i68\6-2.2/socketmodule.o gcc -shared build/temp.linux-i686-2.2/socketmodule.o -L/usr/local/lib -lssl -lc\rypto -o build/lib.linux-i686-2.2/_socket.so ========================== ** If I run ./configure with no switch, I get the same. The AF_INET6 test fails (silently) and I get IPv4. > It is the fallback to ignore the option that bothers > me. The current configure is designed to stop the > build process if a command line option has been > provided, yet the requested feature cannot be > activated. I see what you're saying. OTOH, it appears that the IPv6 configuration is the only part of configure that will terminate the configure script if a test fails. (buggygetaddrinfo also exits on failure). If this is really desired, one could insert an exit in the AC_MSG_CHECKING(if IPv6 can be configured) code if ipv6=0 (one of the four tests failed) _and_ the switch was enabled. > Errors should never pass silently. Unless explicitly > silenced. I'm not sure the user knows that he is silencing any errors. The configure --help merely states that --enable-ipv6=yes will enable IPv6, not that any tests will be bypassed. > If you don't want IPv6 support, build with > --disable-ipv6. yes > If you don't care, build with no option. yes > If you absolutely must have IPv6, configure with > --enable-ipv6. except that you can't have it if you don't have the libraries and runtime support. (Unless there is something going on here that I don't know about :) Sorry this is so long but you asked :-) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 14:12 Message: Logged In: YES user_id=21627 Can you please elaborate on how precisely the build fails on your system, and precisely what software you are using (operating system, C library)? It is the fallback to ignore the option that bothers me. The current configure is designed to stop the build process if a command line option has been provided, yet the requested feature cannot be activated. Errors should never pass silently. Unless explicitly silenced. If you don't want IPv6 support, build with --disable-ipv6. If you don't care, build with no option. If you absolutely must have IPv6, configure with --enable-ipv6. Seems logical to me. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-10-03 13:38 Message: Logged In: YES user_id=149084 Why have configure force a build which is going to fail, or lack runtime support? I guess I'm missing something here :-\ Is the main reason for the switch to provide a way to disable IPv6, or is there also a reason to override the AF_INET6 and RFC2553 tests? The patch ensures that those two tests are run even if the switch is explicitly set, informs the user what the problem is if for some reason the requested IPv6 support cannot be supplied, and provides a graceful fall-back to IPv4. Looking at this again, the current default if no switch is supplied is to attempt to configure IPv6. I chose no IPv6 support; I can provide an updated patch. The spec file is from the current 2.2.1 src.rpm http://www.python.org/2.2.1/rpms.html and Python Patch 611191. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 10:53 Message: Logged In: YES user_id=21627 I fail to see the bug being fixed. An explicit --enable-ipv6 is meant to request explicitly request IPv6 support, overriding the automatic test that happens if you don't provide an option. So the right solution appears to be to change the spec file. I don't know where you got that spec file from, so I can't help here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617906&group_id=5470 From noreply@sourceforge.net Mon Oct 7 22:12:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 14:12:38 -0700 Subject: [Patches] [ python-Patches-510695 ] cycle profiler for VM opcodes Message-ID: Patches item #510695, was opened at 2002-01-30 14:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=510695&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: cycle profiler for VM opcodes Initial Comment: This is just some code I'm noodling around with. It counts the number of cycles each Python VM opcode takes to execute, using the Pentium timestamp counter. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 23:12 Message: Logged In: YES user_id=21627 Is this still of relevance? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=510695&group_id=5470 From noreply@sourceforge.net Mon Oct 7 22:15:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 14:15:16 -0700 Subject: [Patches] [ python-Patches-512981 ] readline /dev/tty problem Message-ID: Patches item #512981, was opened at 2002-02-04 22:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=512981&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Stutzbach (agthorr) Assigned to: Nobody/Anonymous (nobody) Summary: readline /dev/tty problem Initial Comment: GNU readline doesn't work if the C symbol "stdin" is not a tty, even if the python symbol sys.stdin is. This will happen, for example, if a program initially receives input from a pipe, but then changes sys.stdin to read from /dev/tty. (This is how programs like "less" work) Here's a sample program that exhibits this behavior: ------------------------------------------------------------------------ #!/usr/bin/env python import sys mail = sys.stdin.read () sys.stdin = open ('/dev/tty', 'r') import readline foo = raw_input ('add_idea> ') print foo ------------------------------------------------------------------------ You can test this by saving the above program to a file (foo.py), piping data to it, then trying to use GNU readline editing commands at the prompt. E.g.: ------------------------------------------------------------------------ liberty:~$ cat ideas.html | ./foo.py add_idea> asdfsdf^Afoo asdfsdffoo ------------------------------------------------------------------------ The patch attached seems to fix the problem. You may want to grep the source for other modules that may have similar bugs. Also, this patch assumes that the readline module is imported *after* sys.stdin is changed. This much better than nothing (particularly if it's documented), but there may be a better solution. -- Agthorr ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 23:15 Message: Logged In: YES user_id=21627 Are you interested in pursuing this feature? I cannot promise that I will apply it blankly, only that I will review it. ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-04-25 22:02 Message: Logged In: YES user_id=6324 If I create a patch that operates as described in my previous followup, will you apply it? Is there anything I can do to get this integrated into the main python trunk? I don't like having to repatch and rebuild python everytime a new version comes out that I need for some other reason :> ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-02-05 19:21 Message: Logged In: YES user_id=6324 1) Well, it lets python treat sys.stdin as a tty even if C stdin != python sys.stdin. It still checks to make sure sys.stdin is a tty using isatty(). If some user changes sys.stdin to point to a tty, but *wants* Python to treat it as a non-tty, then this might cause them some grief. I can't think of any case where they'd want to do that, though. The behavior would be unchanged when sys.stdin points to a regular file. 2) hmm.. I suppose, ideally, the readline module should smoothly handle sys.stdin being changed out from under it. Readline alters various terminal settings on rl_instream during initialization, though. For example, it changes the terminal to raw or cbreak mode from cooked mode, so that it can receive input a character at a time instead of a line at a time. It may be possible to uninitialized and reinitialized terminal each time call_readline is called, I suppose (I believe libreadline provides hooks for this). It would also have to check if sys.stdin is a tty, and call PyFile_GetLine if it is not. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-02-05 11:35 Message: Logged In: YES user_id=6656 Comments: 1) in what ways does this change existing behaviour? I can think of a few, but are there any that will inconvenience existing users 2) why not do the rl_instream = PySys_GetObject("stdin") dance in call_readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=512981&group_id=5470 From noreply@sourceforge.net Mon Oct 7 22:17:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 14:17:03 -0700 Subject: [Patches] [ python-Patches-515003 ] Added HTTP{,S}ProxyConnection Message-ID: Patches item #515003, was opened at 2002-02-08 22:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=515003&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: Jeremy Hylton (jhylton) Summary: Added HTTP{,S}ProxyConnection Initial Comment: This patch adds HTTP*Connection classes for proxy connections. Authenticated proxies are also supported. One can argue urllib2 already implements this. It does not do HTTPS tunneling through proxies, and this is intended to be lower-level than urllib2. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 23:17 Message: Logged In: YES user_id=21627 misa, is a patch forthcoming? ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-07-15 23:37 Message: Logged In: YES user_id=205865 - I agree about the comments. I'll make them reasonable. - one underscore is fine - I intended to have a patch that works with python 1.5, but then again the module itself doesn't run with 1.5 anyway, so good point. - When you make a connection to a server through a proxy, you have to connect to the proxy, but everything else should be the same, i.e. the Host: field has to refer to the server and so on. I wanted to reuse the code from _set_hostport, which saves the host and port in self.host, self.port. Had to do it twice, once for the proxy hostname, once for the server's. _set_hostport takes care of the default port and of the "hostname:port" syntax, which is convenient. I'll put together a patched patch and upload it. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-07-15 23:21 Message: Logged In: YES user_id=31392 The proposed classes seem useful enough, but I would like to make several suggestions for the implementation. - There are too many comments. Comments should only be added when the intent of the code needs to be explained. We definitely don't need one comment for each line of code. The comment in the HTTPS proxy putrequest() is an example of a helpful comment. - Just use a single underscore for private variables. - Please use string methods instead of the string module. - I don't understand the logic of switching the host/port back and forth. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-07-15 22:52 Message: Logged In: YES user_id=31392 I'll take a look. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-07-12 17:46 Message: Logged In: YES user_id=6380 Assigning to Jeremy in the hope that he can provide a review. ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-06-24 05:03 Message: Logged In: YES user_id=205865 The newer patch is generated against the latest CVS tree, and it provides additional documentation. ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-06-11 20:47 Message: Logged In: YES user_id=205865 Sorry, been caught with a zillion of other things to do. I'll try to reorganize it somehow and ask for opinions. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-11 20:42 Message: Logged In: YES user_id=31392 misa-- any progress on this patch? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-02 00:12 Message: Logged In: YES user_id=6380 OK, thanks; I'll wait! ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-03-01 23:58 Message: Logged In: YES user_id=205865 I will add documentation and show the intended usage. urllib* doesn't deal with proxying over SSL (using CONNECT instead of GET/POST). urllib* also use the compatibility classes, HTTP/HTTPS, instead of HTTPConnection (this is not an argument by itself). Thanks for the suggestion. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-01 23:40 Message: Logged In: YES user_id=6380 This patch fails to seduce me. There's no explanation why this would be useful, or how it should be used, and no documentation, and a hint that urllib2 already does this. Maybe you can get someone who's known on python-dev to champion it, if you think it's useful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=515003&group_id=5470 From noreply@sourceforge.net Mon Oct 7 22:18:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 14:18:35 -0700 Subject: [Patches] [ python-Patches-531901 ] binary packagers Message-ID: Patches item #531901, was opened at 2002-03-19 16:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=531901&group_id=5470 Category: Distutils and setup.py Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Mark Alexander (mwa) Assigned to: M.-A. Lemburg (lemburg) Summary: binary packagers Initial Comment: zip file with updated Solaris and HP-UX packagers. Replaces 415226, 415227, 415228. Changes made to take advantage of new PEP241 changes in the Distribution class. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 23:18 Message: Logged In: YES user_id=21627 Given the recent discussion, I think we consider this patch withdrawn for the moment. If there is any change to its status, please submit a new patch. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-04-27 16:54 Message: Logged In: YES user_id=38388 Mark, I checked in your code, but still need the documentation to not get beaten over the head by Fred ;-) TIA. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-04-17 21:54 Message: Logged In: YES user_id=38388 I will try to checkin your latest version into CVS today. The PSF will still require you to sign a contributor agreement for these addition, though, after these have been through the legal review phase. http://www.python.org/psf/psf-contributor-agreement.html Is that acceptable ? Note: I'm still awaiting the documentation for these files. Thanks. ---------------------------------------------------------------------- Comment By: Mark Alexander (mwa) Date: 2002-04-15 20:54 Message: Logged In: YES user_id=12810 New file submitted. No documentation yet, but I am committed to maintaining them. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-04-11 18:59 Message: Logged In: YES user_id=38388 Mark, could you reupload the ZIP file ? I cannot download it from the SF page (the file is mostly empty). Also, is the documentation already included in the ZIP file ? If not, it would be nice if you could add them as well. I don't require a special PEP for these changes, BTW, but I do require you to maintain them. Thanks. ---------------------------------------------------------------------- Comment By: Mark Alexander (mwa) Date: 2002-03-20 20:55 Message: Logged In: YES user_id=12810 OK, the PEP seems to me to mean most of this is done. These additions are not library modules, they are Distutils "commands". So the way i read it, the Distutils-SIG (where I've been hanging around for some time) are the Maintainers. The documentation will be 2 new chapters for the Distutils manual "Creating Solaris packages" and "Creating HP-UX packages" each looking a whole lot like "Creating RPM packages". Does that clarify anything, or am I still missing a clue? p.s. Thanks for cleaning up the extra uploads! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-03-20 16:35 Message: Logged In: YES user_id=21627 You volunteering as the maintainer is part of the prerequisites of accepting new modules, when following PEP 2, see http://python.sourceforge.net/peps/pep-0002.html It says: "developers ... will first form a group of maintainers. Then, this group shall produce a PEP called a library PEP." So existance of a PEP describing these library extensions would be a prerequisite for accepting them. If MAL wants to waive this requirement, it would be fine with me. However, such a PEP could also share text with the documentation, so it might not be wasted effort. ---------------------------------------------------------------------- Comment By: Mark Alexander (mwa) Date: 2002-03-20 15:49 Message: Logged In: YES user_id=12810 Any of the three (they're all the same). SourceForge hiccuped during the upload, and I don't have permission to delete the duplicates. I don't exactly understand what you mean by applying PEP 2. I uploaded this per Marc Lemburg's request for the latest versions of patches 41522[6-8]. He's acting as as the integrator in this case (see http://mail.python.org/pipermail/distutils-sig/2001-December/002659.html). I let him know about the duplicate uploads, so hopefully he'll correct it. If you can and want, feel free to delete the 2 of your choice. I agree they need to be documented. As soon as I can, I'll submit changes to the Distutils documentation. Finally, yes, I'll act as maintainer. I'm on the Distutils-sig and as soon as some other poor soul who has to deal with Solaris or HP-UX tries them, I'm there to work out issues. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-03-20 08:35 Message: Logged In: YES user_id=21627 Which of the three attached files is the right one (19633, 19634, or 19635)? Unless they are all needed, we should delete the extra copies. I recommend to apply PEP 2 to this patch: A library PEP is needed (which could be quite short), documentation, perhaps test cases. Most importantly, there must be an identified maintainer of these modules. Are you willing to act as the maintainer? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=531901&group_id=5470 From noreply@sourceforge.net Mon Oct 7 22:20:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 14:20:15 -0700 Subject: [Patches] [ python-Patches-515003 ] Added HTTP{,S}ProxyConnection Message-ID: Patches item #515003, was opened at 2002-02-08 16:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=515003&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: Jeremy Hylton (jhylton) Summary: Added HTTP{,S}ProxyConnection Initial Comment: This patch adds HTTP*Connection classes for proxy connections. Authenticated proxies are also supported. One can argue urllib2 already implements this. It does not do HTTPS tunneling through proxies, and this is intended to be lower-level than urllib2. ---------------------------------------------------------------------- >Comment By: Mihai Ibanescu (misa) Date: 2002-10-07 17:20 Message: Logged In: YES user_id=205865 Boy, two months. Yes, I'll go back to working on the patch. Sorry for the delay. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 17:17 Message: Logged In: YES user_id=21627 misa, is a patch forthcoming? ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-07-15 17:37 Message: Logged In: YES user_id=205865 - I agree about the comments. I'll make them reasonable. - one underscore is fine - I intended to have a patch that works with python 1.5, but then again the module itself doesn't run with 1.5 anyway, so good point. - When you make a connection to a server through a proxy, you have to connect to the proxy, but everything else should be the same, i.e. the Host: field has to refer to the server and so on. I wanted to reuse the code from _set_hostport, which saves the host and port in self.host, self.port. Had to do it twice, once for the proxy hostname, once for the server's. _set_hostport takes care of the default port and of the "hostname:port" syntax, which is convenient. I'll put together a patched patch and upload it. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-07-15 17:21 Message: Logged In: YES user_id=31392 The proposed classes seem useful enough, but I would like to make several suggestions for the implementation. - There are too many comments. Comments should only be added when the intent of the code needs to be explained. We definitely don't need one comment for each line of code. The comment in the HTTPS proxy putrequest() is an example of a helpful comment. - Just use a single underscore for private variables. - Please use string methods instead of the string module. - I don't understand the logic of switching the host/port back and forth. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-07-15 16:52 Message: Logged In: YES user_id=31392 I'll take a look. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-07-12 11:46 Message: Logged In: YES user_id=6380 Assigning to Jeremy in the hope that he can provide a review. ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-06-23 23:03 Message: Logged In: YES user_id=205865 The newer patch is generated against the latest CVS tree, and it provides additional documentation. ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-06-11 14:47 Message: Logged In: YES user_id=205865 Sorry, been caught with a zillion of other things to do. I'll try to reorganize it somehow and ask for opinions. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-11 14:42 Message: Logged In: YES user_id=31392 misa-- any progress on this patch? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-01 18:12 Message: Logged In: YES user_id=6380 OK, thanks; I'll wait! ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-03-01 17:58 Message: Logged In: YES user_id=205865 I will add documentation and show the intended usage. urllib* doesn't deal with proxying over SSL (using CONNECT instead of GET/POST). urllib* also use the compatibility classes, HTTP/HTTPS, instead of HTTPConnection (this is not an argument by itself). Thanks for the suggestion. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-01 17:40 Message: Logged In: YES user_id=6380 This patch fails to seduce me. There's no explanation why this would be useful, or how it should be used, and no documentation, and a hint that urllib2 already does this. Maybe you can get someone who's known on python-dev to champion it, if you think it's useful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=515003&group_id=5470 From noreply@sourceforge.net Mon Oct 7 22:21:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 14:21:00 -0700 Subject: [Patches] [ python-Patches-542562 ] clean up trace.py Message-ID: Patches item #542562, was opened at 2002-04-11 18:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=542562&group_id=5470 Category: Demos and tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Skip Montanaro (montanaro) Summary: clean up trace.py Initial Comment: moderately interesting changes: * bugfix: remove "feature" of ignoring files in the tmpdir, as I was trying to run it on file in the tmpdir and couldn't figure out why it gave no answer! I think the original motivation for that feature (spurious "/tmp/" filenames for builtin functions??) has gone away, but I'm not sure. * add more usage docs and warning about common mistake pretty mundane changes: * remove unnecessary checks for backwards compatibility with a version that never escaped from my (Zooko's) laptop * add a future-compatible check: if the interpreter offers an attribute called `sys.optimized', and it is "true", and the user is trying to do something that can't be done with an optimizing interpreter, then error out ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 23:21 Message: Logged In: YES user_id=21627 Skip, what kind of processing do you plan for this patch? ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2002-06-17 17:12 Message: Logged In: YES user_id=52562 This patch removes the change log, as per GvR's request. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2002-06-17 16:57 Message: Logged In: YES user_id=52562 I'll remove the change log and submit a patch momentarily. I'm afraid I cannot legally remove the copyright notice (or more precisely: my removing the copyright notice from the text would have no legal effect, and you can do it as well as I can), since I am not Autonomous Zones Industries, Inc. (AZI was my employer at the time I wrote and submitted that patch.) Regards, Zooko ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-14 12:27 Message: Logged In: YES user_id=21627 Can you also provide the other cleanup that Guido requested (change of license, removal of change logs, etc)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=542562&group_id=5470 From noreply@sourceforge.net Mon Oct 7 22:19:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 14:19:30 -0700 Subject: [Patches] [ python-Patches-535335 ] 2.2 patches for BSD/OS 5.0 Message-ID: Patches item #535335, was opened at 2002-03-26 19:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=535335&group_id=5470 Category: Build Group: Python 2.2.x >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Jeffrey Honig (jchonig) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2 patches for BSD/OS 5.0 Initial Comment: The following patches were necessary to get Python 2.2 to work on BSD/OS 5.0. More may follow as we are still attempting to resolve some issues related to the regression tests (although these may be OS issues). Thanks. Jeff ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 23:19 Message: Logged In: YES user_id=21627 Rejecting the patch because of inactivity. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-23 05:22 Message: Logged In: YES user_id=33168 Jeff, any chances of getting updates for this patch? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 10:49 Message: Logged In: YES user_id=21627 Is an update of this patch forthcoming? ---------------------------------------------------------------------- Comment By: Jeffrey Honig (jchonig) Date: 2002-03-26 20:08 Message: Logged In: YES user_id=96862 Re: configure.in vs configure: we don't use autoconf here so modifying configure.in doesn't help us. I should have copies the changes and submitted them, but then they aren't too hard to figure out.... Re: contrib{lib/include}: We install many of the packages that we install from the net (which we call contrib packages) into the /usr/contrib heirarchy. They won't be found by setup.py unless those paths are present. Re: regrtest.py: Apologies about the regrtest.py content, there are some tests in there that shouldn't be, ignore it for now, I'll submit an update later. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-03-26 19:53 Message: Logged In: YES user_id=33168 Lib/posixfile.py & Lib/test/test_fcntl.py seem harmless. configure is generated, so configure.in will need the changes made to it. There seem to be many tests which fail, but perhaps shouldn't: fork1, locale, minidom, poll, pyexpat, sax, unicode_file? I'm also unsure of the benefit of adding contrib/{lib/include} to setup.py. This could be fine, but I don't know anything about distutils. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=535335&group_id=5470 From noreply@sourceforge.net Mon Oct 7 22:26:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 14:26:35 -0700 Subject: [Patches] [ python-Patches-544909 ] addition of cmath.arg function Message-ID: Patches item #544909, was opened at 2002-04-17 01:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=544909&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: John Williams (johnw42) Assigned to: Tim Peters (tim_one) Summary: addition of cmath.arg function Initial Comment: This patch adds the familiar "Arg" function from complex analysis to the cmath module, though it's called "arg" here for consistency with the other names. Along with the built-in abs function this makes polar/rectangular coordinate conversions trivial: z = complex(x,y) r, theta = abs(z), arg(z) z = r * exp(1j * theta) x, y = z.real, z.imag ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 23:26 Message: Logged In: YES user_id=21627 Since Raymond's analysis is uncommented, I reject this patch. John, if you can find a rationale for this change based on practicality, not purity, feel free to post it here - we will still see your comments. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-06-26 10:05 Message: Logged In: YES user_id=80475 It takes only a couple of minutes to get used to the existing functions, so I don't think any of the three should be added. ---------------------------------------------------------------------- Comment By: John Williams (johnw42) Date: 2002-04-22 21:17 Message: Logged In: YES user_id=44174 You have a good point; the functions you suggest *are* a lot closer to what is needed in practice, but at the same time something just bothers me about a function I learned about in the first week of complex analysis not being in the complex math module--kind of like saying you don't need tan since it's just really just sin/cos. How would you feel about adding all three? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-04-22 20:08 Message: Logged In: YES user_id=31435 It's hard to know what to say -- since it's really just an alias for math.atan2, it's hard to get excited about. Might it be even more convenient to add cmath.polar(complex) -> (abs, arg) cmath.rect(abs, arg) -> complex functions? That is, what do you *really* want ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-22 19:53 Message: Logged In: YES user_id=6380 For Tim to pronounce. ---------------------------------------------------------------------- Comment By: John Williams (johnw42) Date: 2002-04-19 19:38 Message: Logged In: YES user_id=44174 I forgot to mention this patch is relative to version 2.2.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=544909&group_id=5470 From noreply@sourceforge.net Mon Oct 7 22:30:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 14:30:08 -0700 Subject: [Patches] [ python-Patches-552605 ] Fix broken smtplib.login() Message-ID: Patches item #552605, was opened at 2002-05-05 20:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=552605&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Andrew Rucker Jones (arjones) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Fix broken smtplib.login() Initial Comment: RFC 2554 explicitly states that all base64 data in SMTP AUTH challenges and responses can be of arbitrary length, but the base64 module adds a newline after 57 bytes of binary data that it has converted to ascii. This is not accounted for in smtplib.login(), leading to extraneous newline characters in the middle of long responses that do weird things to the SMTP session. The patch is for smtplib.py already patched with the patch from SourceForge patch ID 552060 and fixes this problem. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 23:30 Message: Logged In: YES user_id=21627 Now that the AUTH=LOGIN patch is committed, can somebody explain what needs to be done with this patch? ---------------------------------------------------------------------- Comment By: Andrew Rucker Jones (arjones) Date: 2002-07-17 20:40 Message: Logged In: YES user_id=236100 Not that my opinion matters much, but i'm all for ghaering's solution. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-06-30 23:20 Message: Logged In: YES user_id=163326 I'd suggest to apply this simple patch for the 2.2 maintenance line and use email.base64MIME.encode in the CVS version. This way we could move on without having to keep this patch in the queue. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-06-30 17:58 Message: Logged In: YES user_id=12800 We should probably be using the email.base64MIME package instead of base64. The former is more RFC compliant for email and related functions. email.base64MIME.encode(s, eol='') will eliminate the newlines. However base64MIME is only present in Python 2.3 cvs. It may be backported to Python 2.2.2, but I'm not sure about that yet. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-06-21 12:42 Message: Logged In: YES user_id=163326 Good spot! I've incorporated this patch into my AUTH=LOGIN support with patch #572031. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=552605&group_id=5470 From noreply@sourceforge.net Mon Oct 7 22:32:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 14:32:25 -0700 Subject: [Patches] [ python-Patches-512981 ] readline /dev/tty problem Message-ID: Patches item #512981, was opened at 2002-02-04 13:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=512981&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Stutzbach (agthorr) Assigned to: Nobody/Anonymous (nobody) Summary: readline /dev/tty problem Initial Comment: GNU readline doesn't work if the C symbol "stdin" is not a tty, even if the python symbol sys.stdin is. This will happen, for example, if a program initially receives input from a pipe, but then changes sys.stdin to read from /dev/tty. (This is how programs like "less" work) Here's a sample program that exhibits this behavior: ------------------------------------------------------------------------ #!/usr/bin/env python import sys mail = sys.stdin.read () sys.stdin = open ('/dev/tty', 'r') import readline foo = raw_input ('add_idea> ') print foo ------------------------------------------------------------------------ You can test this by saving the above program to a file (foo.py), piping data to it, then trying to use GNU readline editing commands at the prompt. E.g.: ------------------------------------------------------------------------ liberty:~$ cat ideas.html | ./foo.py add_idea> asdfsdf^Afoo asdfsdffoo ------------------------------------------------------------------------ The patch attached seems to fix the problem. You may want to grep the source for other modules that may have similar bugs. Also, this patch assumes that the readline module is imported *after* sys.stdin is changed. This much better than nothing (particularly if it's documented), but there may be a better solution. -- Agthorr ---------------------------------------------------------------------- >Comment By: Daniel Stutzbach (agthorr) Date: 2002-10-07 14:32 Message: Logged In: YES user_id=6324 Yes, I'm interested in pursuing it. Let me know what I can do to move this along. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 14:15 Message: Logged In: YES user_id=21627 Are you interested in pursuing this feature? I cannot promise that I will apply it blankly, only that I will review it. ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-04-25 13:02 Message: Logged In: YES user_id=6324 If I create a patch that operates as described in my previous followup, will you apply it? Is there anything I can do to get this integrated into the main python trunk? I don't like having to repatch and rebuild python everytime a new version comes out that I need for some other reason :> ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-02-05 10:21 Message: Logged In: YES user_id=6324 1) Well, it lets python treat sys.stdin as a tty even if C stdin != python sys.stdin. It still checks to make sure sys.stdin is a tty using isatty(). If some user changes sys.stdin to point to a tty, but *wants* Python to treat it as a non-tty, then this might cause them some grief. I can't think of any case where they'd want to do that, though. The behavior would be unchanged when sys.stdin points to a regular file. 2) hmm.. I suppose, ideally, the readline module should smoothly handle sys.stdin being changed out from under it. Readline alters various terminal settings on rl_instream during initialization, though. For example, it changes the terminal to raw or cbreak mode from cooked mode, so that it can receive input a character at a time instead of a line at a time. It may be possible to uninitialized and reinitialized terminal each time call_readline is called, I suppose (I believe libreadline provides hooks for this). It would also have to check if sys.stdin is a tty, and call PyFile_GetLine if it is not. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-02-05 02:35 Message: Logged In: YES user_id=6656 Comments: 1) in what ways does this change existing behaviour? I can think of a few, but are there any that will inconvenience existing users 2) why not do the rl_instream = PySys_GetObject("stdin") dance in call_readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=512981&group_id=5470 From noreply@sourceforge.net Mon Oct 7 22:32:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 14:32:31 -0700 Subject: [Patches] [ python-Patches-555251 ] Mutable object change flag Message-ID: Patches item #555251, was opened at 2002-05-13 02:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=555251&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 1 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Mutable object change flag Initial Comment: This patch is a proof-of-concept for marking state changes in mutable objects. It is meant as a simpler, faster alternative to a full built-in observer pattern. Here's the whole protocol: Mutable objects choosing to implement the protocol provide a writable attribute, cachevalid, which is initialized to zero. Upon any update to the object, the attribute is reset to zero. Callers who set the attribute to one can later check to see if an update has occurred (as indicated by a zero). >>> a = list('abcd') >>> a.cachevalid 0 >>> a.cachevalid=1 >>> a.cachevalid 1 >>> a[2] = 'k' >>> a.cachevalid 0 The proof-of-concept patch is implemented only for lists. A production version would need to include dictionaries. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 23:32 Message: Logged In: YES user_id=21627 Raymond, are you still interested in this approach? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=555251&group_id=5470 From noreply@sourceforge.net Mon Oct 7 22:44:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 14:44:20 -0700 Subject: [Patches] [ python-Patches-559288 ] Use builtin boolean if present Message-ID: Patches item #559288, was opened at 2002-05-22 19:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=559288&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Fredrik Lundh (effbot) Summary: Use builtin boolean if present Initial Comment: Now that Python has a boolean type, perhaps xmlrpclib should use it if available. Here's a patch that (I think) does what's necessary. The existing test case (which does manipulate a boolean) passes. Haven't tested it with a pre-bool version of Python though. Skip ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 23:44 Message: Logged In: YES user_id=21627 I think xmlrpclib.{True,False} must stay, even though they could become aliases for the builtin True and False (notice that you can access True with bool(1)) The module must stay 1.5.2 compatible, I think this is currently not the case: dispatching is based on the type, but type(True) will be ClassType in 1.5.2. The test looks for True to determine presence of the boolean type; this is incorrect: Python 2.2 has True without having bool. The test also binds x without reason. I'd suggest try: boolean = bool except: ... instead ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-02 19:03 Message: Logged In: YES user_id=44345 updated patch which avoids using types.BooleanType since there was so much pushback on the idea. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-05-22 19:46 Message: Logged In: YES user_id=44345 new patch - don't know why running the test suite didn't catch the NameError... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=559288&group_id=5470 From noreply@sourceforge.net Mon Oct 7 22:46:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 14:46:06 -0700 Subject: [Patches] [ python-Patches-562501 ] Add isxxx() methods to string objects Message-ID: Patches item #562501, was opened at 2002-05-30 20:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=562501&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Add isxxx() methods to string objects Initial Comment: Here's the patch for the isxxx methods. If it's up to spec, let me know and I'll add documentation and expand the unittests. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 23:46 Message: Logged In: YES user_id=21627 Raymond, any news on this? I like the idea. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-06-30 21:58 Message: Logged In: YES user_id=80475 Unassigning this because I'm away for five weeks. The equivalent Unicode operations are not as clearly defined as they are for Ascii. Was researching what is done in other programming languages. Also, there was a py-dev discussion that suggested that the function names be changed to something more clear than their names in C. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-30 20:41 Message: Logged In: YES user_id=6380 Thanks! But what about adding the same methods to Unicode objects? I think that's the point of using methods -- supporting the same operations for both string types. Also, Paul Prescod wanted ishexdigit instead of isxdigit. Not sure if I agree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=562501&group_id=5470 From noreply@sourceforge.net Mon Oct 7 22:48:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 14:48:08 -0700 Subject: [Patches] [ python-Patches-569139 ] Implementation of major, minor and makedev Message-ID: Patches item #569139, was opened at 2002-06-14 20:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=569139&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) >Assigned to: Martin v. Löwis (loewis) Summary: Implementation of major, minor and makedev Initial Comment: As discussed in python-dev, st_rdev provides an integer, which usually needs to be translated in a (major, minor) pair before it's useful. There are no implementations of major() and minor() in the current library, and maybe there shouldn't be, since their functionality is not portable. This patch provides a portable way to access this information, by providing a new attribute to the os.stat() return tuple named st_rdev_pair. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 23:48 Message: Logged In: YES user_id=21627 Is anything stopping this patch? If not, I'll apply it. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-06-15 21:04 Message: Logged In: YES user_id=7887 I'm not sure if that's really the right way to implement the needed features for tarfile. Maybe including major, minor, and makedev could be the way to go. I'm sending the rationale to python-dev for discussion, and attaching a new patch with their implementations, instead of st_rdev_pair. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-06-15 00:23 Message: Logged In: YES user_id=7887 I'll redo the patch with a test. Thanks! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-15 00:02 Message: Logged In: YES user_id=33168 You are correct about the DECREF, it is not necessary. I'm not sure if any standards define major/minor (that's why I asked). What platform(s) did you test on? ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-06-14 23:47 Message: Logged In: YES user_id=7887 I don't think a test is needed. If st_rdev is available, this information must be decodable by the system, and this is done by the major/minor pair, AFAIK. About the DECREF, I don't think it's needed. w's reference is stolen by v when PyStructSequence_SET_ITEM is run, and will be destroyed with v once it's DECREF'd. If that's not true, the whole logic is wrong in that function. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-14 23:36 Message: Logged In: YES user_id=33168 Are major/minor guaranteed to exist? Should a check be added to configure? There is a missing DECREF. In the last line of the patch to posixmodule.c, there is if (PyErr_Occurred()) { In that block, w needs to be DECREFed. You can initialize w = NULL in the declaration, then do an XDECREF in the error block. That way you don't need to handle the error creating w, if w != NULL, set the items in the tuple. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=569139&group_id=5470 From noreply@sourceforge.net Mon Oct 7 23:28:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 15:28:01 -0700 Subject: [Patches] [ python-Patches-552605 ] Fix broken smtplib.login() Message-ID: Patches item #552605, was opened at 2002-05-05 20:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=552605&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Andrew Rucker Jones (arjones) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Fix broken smtplib.login() Initial Comment: RFC 2554 explicitly states that all base64 data in SMTP AUTH challenges and responses can be of arbitrary length, but the base64 module adds a newline after 57 bytes of binary data that it has converted to ascii. This is not accounted for in smtplib.login(), leading to extraneous newline characters in the middle of long responses that do weird things to the SMTP session. The patch is for smtplib.py already patched with the patch from SourceForge patch ID 552060 and fixes this problem. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-10-08 00:28 Message: Logged In: YES user_id=163326 The patch addressed a problem, but the proposed fix was WRONG. Just as wrong as my original SMTP auth code, though (using [:-1] to remove the newlines from base64.encode, which is WRONG because there might be multiple newlines in there). In my now committed there was a correct solution using email.base64MIME.encode resp. a workaround for Python 2.2. So I'd propose to close this as 'Fixed'. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 23:30 Message: Logged In: YES user_id=21627 Now that the AUTH=LOGIN patch is committed, can somebody explain what needs to be done with this patch? ---------------------------------------------------------------------- Comment By: Andrew Rucker Jones (arjones) Date: 2002-07-17 20:40 Message: Logged In: YES user_id=236100 Not that my opinion matters much, but i'm all for ghaering's solution. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-06-30 23:20 Message: Logged In: YES user_id=163326 I'd suggest to apply this simple patch for the 2.2 maintenance line and use email.base64MIME.encode in the CVS version. This way we could move on without having to keep this patch in the queue. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-06-30 17:58 Message: Logged In: YES user_id=12800 We should probably be using the email.base64MIME package instead of base64. The former is more RFC compliant for email and related functions. email.base64MIME.encode(s, eol='') will eliminate the newlines. However base64MIME is only present in Python 2.3 cvs. It may be backported to Python 2.2.2, but I'm not sure about that yet. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-06-21 12:42 Message: Logged In: YES user_id=163326 Good spot! I've incorporated this patch into my AUTH=LOGIN support with patch #572031. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=552605&group_id=5470 From noreply@sourceforge.net Mon Oct 7 23:30:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 15:30:41 -0700 Subject: [Patches] [ python-Patches-552605 ] Fix broken smtplib.login() Message-ID: Patches item #552605, was opened at 2002-05-05 20:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=552605&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Andrew Rucker Jones (arjones) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Fix broken smtplib.login() Initial Comment: RFC 2554 explicitly states that all base64 data in SMTP AUTH challenges and responses can be of arbitrary length, but the base64 module adds a newline after 57 bytes of binary data that it has converted to ascii. This is not accounted for in smtplib.login(), leading to extraneous newline characters in the middle of long responses that do weird things to the SMTP session. The patch is for smtplib.py already patched with the patch from SourceForge patch ID 552060 and fixes this problem. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-10-08 00:30 Message: Logged In: YES user_id=163326 Argh. Sorry - I was talking utter, complete garbage. Of course the fix in this patch is correct (I was downloading the patch before, but too stupid to read diffs). It's still already taken care of in what's committed already. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-10-08 00:28 Message: Logged In: YES user_id=163326 The patch addressed a problem, but the proposed fix was WRONG. Just as wrong as my original SMTP auth code, though (using [:-1] to remove the newlines from base64.encode, which is WRONG because there might be multiple newlines in there). In my now committed there was a correct solution using email.base64MIME.encode resp. a workaround for Python 2.2. So I'd propose to close this as 'Fixed'. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 23:30 Message: Logged In: YES user_id=21627 Now that the AUTH=LOGIN patch is committed, can somebody explain what needs to be done with this patch? ---------------------------------------------------------------------- Comment By: Andrew Rucker Jones (arjones) Date: 2002-07-17 20:40 Message: Logged In: YES user_id=236100 Not that my opinion matters much, but i'm all for ghaering's solution. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-06-30 23:20 Message: Logged In: YES user_id=163326 I'd suggest to apply this simple patch for the 2.2 maintenance line and use email.base64MIME.encode in the CVS version. This way we could move on without having to keep this patch in the queue. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-06-30 17:58 Message: Logged In: YES user_id=12800 We should probably be using the email.base64MIME package instead of base64. The former is more RFC compliant for email and related functions. email.base64MIME.encode(s, eol='') will eliminate the newlines. However base64MIME is only present in Python 2.3 cvs. It may be backported to Python 2.2.2, but I'm not sure about that yet. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-06-21 12:42 Message: Logged In: YES user_id=163326 Good spot! I've incorporated this patch into my AUTH=LOGIN support with patch #572031. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=552605&group_id=5470 From noreply@sourceforge.net Tue Oct 8 03:47:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 19:47:14 -0700 Subject: [Patches] [ python-Patches-619108 ] Fix test_pep277 on Win9x Message-ID: Patches item #619108, was opened at 2002-10-06 11:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619108&group_id=5470 Category: Windows Group: None Status: Open >Resolution: Fixed Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: Fix test_pep277 on Win9x Initial Comment: In the interests of getting test_pep277 running for Tim , sys.getwindowsversion() should be added. Chose sys as that is where all other version related information is found. Happy to move to the os module is desired, but posixmodule.c is enough of a mess already. Patch even includes doc :) Martin, could you please review? ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2002-10-08 12:47 Message: Logged In: YES user_id=14198 OK, all checked in, including a new enhanced sys.getwindowsversion() that returns a tuple. Just don't complain about the magic numbers /cvsroot/python/python/dist/src/Python/sysmodule.c,v <-- sysmodule.c new revision: 2.111; previous revision: 2.110 /cvsroot/python/python/dist/src/Doc/lib/libsys.tex,v <-- libsys.tex new revision: 1.61; previous revision: 1.60 /cvsroot/python/python/dist/src/Doc/lib/libposixpath.tex,v <-- libposixpath.tex new revision: 1.29; previous revision: 1.28 /cvsroot/python/python/dist/src/Lib/dospath.py,v <-- dospath.py new revision: 1.30; previous revision: 1.29 /cvsroot/python/python/dist/src/Lib/macpath.py,v <-- macpath.py new revision: 1.40; previous revision: 1.39 /cvsroot/python/python/dist/src/Lib/ntpath.py,v <-- ntpath.py new revision: 1.50; previous revision: 1.49 /cvsroot/python/python/dist/src/Lib/os2emxpath.py,v <-- os2emxpath.py new revision: 1.7; previous revision: 1.6 /cvsroot/python/python/dist/src/Lib/posixpath.py,v <-- posixpath.py new revision: 1.53; previous revision: 1.52 /cvsroot/python/python/dist/src/Lib/test/test_pep277.py,v <-- test_pep277.py new revision: 1.4; previous revision: 1.3 /cvsroot/python/python/dist/src/Lib/test/output/test_pep277,v <-- test_pep277 new revision: 1.2; previous revision: 1.1 /cvsroot/python/python/dist/src/Misc/NEWS,v <-- NEWS new revision: 1.495; previous revision: 1.494 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 00:17 Message: Logged In: YES user_id=21627 Right; that's os.path.supports_unicode_filenames. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-06 23:30 Message: Logged In: YES user_id=6380 But sys.path.supports_unicode_filenames was a typo, right? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 22:18 Message: Logged In: YES user_id=21627 Mark wants it to be in sys; I have no preference in either direction. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-06 21:53 Message: Logged In: YES user_id=6380 Did you mean sys, or os? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 21:41 Message: Logged In: YES user_id=21627 Attached is a patch that uses getwindowsversion as I just suggested. Back to Mark for comments and possible checkin. The libsys.tex change also needs a \versionadded. If sys.getwindowsversion remains signed, this patch must be adjusted. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 17:25 Message: Logged In: YES user_id=21627 I'm in favour of adding sys.getwindowsversion. As for disabling the test, it seems like Tim prefers to add sys.path.supports_unicode_filenames, with the following settings: posixpath, macpath, dospath, os2emxpath: False ntpath: getwindowsversion() < 0x80000000 I'm somewhat confused about the signedness of GetVersion(), though - it appears that it is unsigned in C. If so, I think the Python wrapper should also return non-negative numbers only. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619108&group_id=5470 From noreply@sourceforge.net Tue Oct 8 10:21:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 02:21:02 -0700 Subject: [Patches] [ python-Patches-614770 ] MSVC 7.0 compiler support Message-ID: Patches item #614770, was opened at 2002-09-26 05:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614770&group_id=5470 Category: Distutils and setup.py Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: John Anderson (djohnanderson) Assigned to: Nobody/Anonymous (nobody) Summary: MSVC 7.0 compiler support Initial Comment: Distutils doesn't work with the current shipping version of the Microsoft compiler (7.0). I've got a patch that fixes it (context diffs of msvccompiler.py against the latest code in CVS). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-08 11:21 Message: Logged In: YES user_id=21627 I'm asking because you are not looking into Software\Microsoft\Devstudio anymore to find the most recent version. Not supporting MSVC5 anymore is probably acceptable. I never noticed that support for MSVC6 is broken - it works fine for me... However, if you think you can improve that somehow, please do - please elaborate what changes solve what problems, though. It seems that a number of changes are not strictly necessary (e.g. creation of new functions), to really evaluate the patch, I have to know why you propose these changes. ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-10-07 17:27 Message: Logged In: YES user_id=618290 It's been so long since I had a copy of MSVC 5 -- I think it became obsolete about 6 or 7 years ago. None of my changes should have any impact on the operation of MSVC 5, but of course you never know unless you try it. Also, the MSVC 6 support in distutils is currently broken -- although it finds the compiler, the code to find the include paths is totally broken. I have MSVC 6 (latest service pack) and 7 and would be willing to make both those work. Anyone who's using 5 is going to have lots of other problems to deal with besides distutils. Wouldn't surprise me if the MSVC 6 code for finding paths would differ in each service pack -- since it depends upon unsupported registry entries. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 13:43 Message: Logged In: YES user_id=21627 Can you report whether this patch works with MSVC 5? ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-09-26 23:38 Message: Logged In: YES user_id=618290 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-09-26 23:38 Message: Logged In: YES user_id=618290 Opps, I guess I forgot to check that little box. Sorry about that. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 06:30 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614770&group_id=5470 From noreply@sourceforge.net Tue Oct 8 10:27:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 02:27:00 -0700 Subject: [Patches] [ python-Patches-512981 ] readline /dev/tty problem Message-ID: Patches item #512981, was opened at 2002-02-04 22:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=512981&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Stutzbach (agthorr) Assigned to: Nobody/Anonymous (nobody) Summary: readline /dev/tty problem Initial Comment: GNU readline doesn't work if the C symbol "stdin" is not a tty, even if the python symbol sys.stdin is. This will happen, for example, if a program initially receives input from a pipe, but then changes sys.stdin to read from /dev/tty. (This is how programs like "less" work) Here's a sample program that exhibits this behavior: ------------------------------------------------------------------------ #!/usr/bin/env python import sys mail = sys.stdin.read () sys.stdin = open ('/dev/tty', 'r') import readline foo = raw_input ('add_idea> ') print foo ------------------------------------------------------------------------ You can test this by saving the above program to a file (foo.py), piping data to it, then trying to use GNU readline editing commands at the prompt. E.g.: ------------------------------------------------------------------------ liberty:~$ cat ideas.html | ./foo.py add_idea> asdfsdf^Afoo asdfsdffoo ------------------------------------------------------------------------ The patch attached seems to fix the problem. You may want to grep the source for other modules that may have similar bugs. Also, this patch assumes that the readline module is imported *after* sys.stdin is changed. This much better than nothing (particularly if it's documented), but there may be a better solution. -- Agthorr ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-08 11:27 Message: Logged In: YES user_id=21627 I think you should implement a strategy to detect changes to sys.stdin dynamically. For example, the old sys.stdin could go away, closing the file, which would leave readline with a garbage pointer. Instead, I think you should hold onto sys.stdin, and compare this reference from time to time with the current sys.stdin, and arrange to reinitialize readline (if possible). ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-10-07 23:32 Message: Logged In: YES user_id=6324 Yes, I'm interested in pursuing it. Let me know what I can do to move this along. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 23:15 Message: Logged In: YES user_id=21627 Are you interested in pursuing this feature? I cannot promise that I will apply it blankly, only that I will review it. ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-04-25 22:02 Message: Logged In: YES user_id=6324 If I create a patch that operates as described in my previous followup, will you apply it? Is there anything I can do to get this integrated into the main python trunk? I don't like having to repatch and rebuild python everytime a new version comes out that I need for some other reason :> ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-02-05 19:21 Message: Logged In: YES user_id=6324 1) Well, it lets python treat sys.stdin as a tty even if C stdin != python sys.stdin. It still checks to make sure sys.stdin is a tty using isatty(). If some user changes sys.stdin to point to a tty, but *wants* Python to treat it as a non-tty, then this might cause them some grief. I can't think of any case where they'd want to do that, though. The behavior would be unchanged when sys.stdin points to a regular file. 2) hmm.. I suppose, ideally, the readline module should smoothly handle sys.stdin being changed out from under it. Readline alters various terminal settings on rl_instream during initialization, though. For example, it changes the terminal to raw or cbreak mode from cooked mode, so that it can receive input a character at a time instead of a line at a time. It may be possible to uninitialized and reinitialized terminal each time call_readline is called, I suppose (I believe libreadline provides hooks for this). It would also have to check if sys.stdin is a tty, and call PyFile_GetLine if it is not. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-02-05 11:35 Message: Logged In: YES user_id=6656 Comments: 1) in what ways does this change existing behaviour? I can think of a few, but are there any that will inconvenience existing users 2) why not do the rl_instream = PySys_GetObject("stdin") dance in call_readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=512981&group_id=5470 From noreply@sourceforge.net Tue Oct 8 10:29:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 02:29:02 -0700 Subject: [Patches] [ python-Patches-552605 ] Fix broken smtplib.login() Message-ID: Patches item #552605, was opened at 2002-05-05 20:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=552605&group_id=5470 Category: Library (Lib) Group: Python 2.2.x >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Andrew Rucker Jones (arjones) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Fix broken smtplib.login() Initial Comment: RFC 2554 explicitly states that all base64 data in SMTP AUTH challenges and responses can be of arbitrary length, but the base64 module adds a newline after 57 bytes of binary data that it has converted to ascii. This is not accounted for in smtplib.login(), leading to extraneous newline characters in the middle of long responses that do weird things to the SMTP session. The patch is for smtplib.py already patched with the patch from SourceForge patch ID 552060 and fixes this problem. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-08 11:29 Message: Logged In: YES user_id=21627 Ok, closing as a duplicate, then. Thanks for your efforts. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-10-08 00:30 Message: Logged In: YES user_id=163326 Argh. Sorry - I was talking utter, complete garbage. Of course the fix in this patch is correct (I was downloading the patch before, but too stupid to read diffs). It's still already taken care of in what's committed already. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-10-08 00:28 Message: Logged In: YES user_id=163326 The patch addressed a problem, but the proposed fix was WRONG. Just as wrong as my original SMTP auth code, though (using [:-1] to remove the newlines from base64.encode, which is WRONG because there might be multiple newlines in there). In my now committed there was a correct solution using email.base64MIME.encode resp. a workaround for Python 2.2. So I'd propose to close this as 'Fixed'. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 23:30 Message: Logged In: YES user_id=21627 Now that the AUTH=LOGIN patch is committed, can somebody explain what needs to be done with this patch? ---------------------------------------------------------------------- Comment By: Andrew Rucker Jones (arjones) Date: 2002-07-17 20:40 Message: Logged In: YES user_id=236100 Not that my opinion matters much, but i'm all for ghaering's solution. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-06-30 23:20 Message: Logged In: YES user_id=163326 I'd suggest to apply this simple patch for the 2.2 maintenance line and use email.base64MIME.encode in the CVS version. This way we could move on without having to keep this patch in the queue. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-06-30 17:58 Message: Logged In: YES user_id=12800 We should probably be using the email.base64MIME package instead of base64. The former is more RFC compliant for email and related functions. email.base64MIME.encode(s, eol='') will eliminate the newlines. However base64MIME is only present in Python 2.3 cvs. It may be backported to Python 2.2.2, but I'm not sure about that yet. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-06-21 12:42 Message: Logged In: YES user_id=163326 Good spot! I've incorporated this patch into my AUTH=LOGIN support with patch #572031. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=552605&group_id=5470 From noreply@sourceforge.net Tue Oct 8 16:51:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 08:51:33 -0700 Subject: [Patches] [ python-Patches-614770 ] MSVC 7.0 compiler support Message-ID: Patches item #614770, was opened at 2002-09-25 20:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614770&group_id=5470 Category: Distutils and setup.py Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: John Anderson (djohnanderson) Assigned to: Nobody/Anonymous (nobody) Summary: MSVC 7.0 compiler support Initial Comment: Distutils doesn't work with the current shipping version of the Microsoft compiler (7.0). I've got a patch that fixes it (context diffs of msvccompiler.py against the latest code in CVS). ---------------------------------------------------------------------- >Comment By: John Anderson (djohnanderson) Date: 2002-10-08 08:51 Message: Logged In: YES user_id=618290 Thanks Martin for taking the time to review my proposed changes. I think your comments about looking in Software\Microsoft\VisualStudio instead of Software\Microsoft\DevStudio is a good point. I decided to two look only in VisualStudio because that works for both the version 6 and 7 compiler I tested with. I don't know if the version 5 compiler also stores the version in DevStudio. Another alternative, which would of course complicate code, would be two look in both places and choose the highest version. Let me know if that's what you'd prefer and I'll upload a new patch. The problem I'm having with the version 6 compiler (latest service Pack 5) is that SOFTWARE\Microsoft\Devstudio\6.0\Build System\ doesn't exist. Instead it looks like it's been moved to SOFTWARE\Microsoft\Shared Tools\Build System\, but in that new location, SOFTWARE\Microsoft\Shared Tools\Build System\Components\Platforms\Win32 (x86)\Directories doesn't exist. This has the effect of not getting the correct include directories for builds. This also points out a serious flaw in looking at undocumented registry entries to find information for the build -- there's no guarantee that the registry information won't change even within the same version of the compiler. I don't have a good solution for this problem, but I'd rather distutils reported an error when it couldn't find the registry entries it expected -- rather than silently ignoring it as it does now. In a few places I added code to report unexpected missing registry entries, but not all. I could if you're interested add error code in all cases. Fixing the problem I'm having with the version 6 compiler seems difficult, since it seems to work for you and doesn't work for me -- apparently are registries are different. Personally I'm content with leaving the version 6 compiler broken since it isn't obvious how to fix it and it apparently works for some people and I only intend to use the version 7 or newer compilers. I added three new functions: convert_mbcs, read_key, and by far the largest: expand_macros. The first two make the code simpler, easier to read, avoid unnecessary duplications, and minimize the risk that someone would forget to deal with mbcs. It would be difficult to understand the bug fix without these two functions. My hope was that these changes would make it easier for the next person who needs to learn the code. The last, expand_macros, is necessary because the version 7 compiler introduces macros which didn't exist in previous versions of the compiler. It would be awkward to implement the macros without having adding a new function. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-08 02:21 Message: Logged In: YES user_id=21627 I'm asking because you are not looking into Software\Microsoft\Devstudio anymore to find the most recent version. Not supporting MSVC5 anymore is probably acceptable. I never noticed that support for MSVC6 is broken - it works fine for me... However, if you think you can improve that somehow, please do - please elaborate what changes solve what problems, though. It seems that a number of changes are not strictly necessary (e.g. creation of new functions), to really evaluate the patch, I have to know why you propose these changes. ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-10-07 08:27 Message: Logged In: YES user_id=618290 It's been so long since I had a copy of MSVC 5 -- I think it became obsolete about 6 or 7 years ago. None of my changes should have any impact on the operation of MSVC 5, but of course you never know unless you try it. Also, the MSVC 6 support in distutils is currently broken -- although it finds the compiler, the code to find the include paths is totally broken. I have MSVC 6 (latest service pack) and 7 and would be willing to make both those work. Anyone who's using 5 is going to have lots of other problems to deal with besides distutils. Wouldn't surprise me if the MSVC 6 code for finding paths would differ in each service pack -- since it depends upon unsupported registry entries. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 04:43 Message: Logged In: YES user_id=21627 Can you report whether this patch works with MSVC 5? ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-09-26 14:38 Message: Logged In: YES user_id=618290 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-09-26 14:38 Message: Logged In: YES user_id=618290 Opps, I guess I forgot to check that little box. Sorry about that. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-25 21:30 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614770&group_id=5470 From noreply@sourceforge.net Tue Oct 8 20:17:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 12:17:10 -0700 Subject: [Patches] [ python-Patches-569139 ] Implementation of major, minor and makedev Message-ID: Patches item #569139, was opened at 2002-06-14 14:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=569139&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Martin v. Löwis (loewis) Summary: Implementation of major, minor and makedev Initial Comment: As discussed in python-dev, st_rdev provides an integer, which usually needs to be translated in a (major, minor) pair before it's useful. There are no implementations of major() and minor() in the current library, and maybe there shouldn't be, since their functionality is not portable. This patch provides a portable way to access this information, by providing a new attribute to the os.stat() return tuple named st_rdev_pair. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-08 15:17 Message: Logged In: YES user_id=33168 I'm fine with checking in. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 17:48 Message: Logged In: YES user_id=21627 Is anything stopping this patch? If not, I'll apply it. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-06-15 15:04 Message: Logged In: YES user_id=7887 I'm not sure if that's really the right way to implement the needed features for tarfile. Maybe including major, minor, and makedev could be the way to go. I'm sending the rationale to python-dev for discussion, and attaching a new patch with their implementations, instead of st_rdev_pair. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-06-14 18:23 Message: Logged In: YES user_id=7887 I'll redo the patch with a test. Thanks! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-14 18:02 Message: Logged In: YES user_id=33168 You are correct about the DECREF, it is not necessary. I'm not sure if any standards define major/minor (that's why I asked). What platform(s) did you test on? ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-06-14 17:47 Message: Logged In: YES user_id=7887 I don't think a test is needed. If st_rdev is available, this information must be decodable by the system, and this is done by the major/minor pair, AFAIK. About the DECREF, I don't think it's needed. w's reference is stolen by v when PyStructSequence_SET_ITEM is run, and will be destroyed with v once it's DECREF'd. If that's not true, the whole logic is wrong in that function. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-14 17:36 Message: Logged In: YES user_id=33168 Are major/minor guaranteed to exist? Should a check be added to configure? There is a missing DECREF. In the last line of the patch to posixmodule.c, there is if (PyErr_Occurred()) { In that block, w needs to be DECREFed. You can initialize w = NULL in the declaration, then do an XDECREF in the error block. That way you don't need to handle the error creating w, if w != NULL, set the items in the tuple. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=569139&group_id=5470 From noreply@sourceforge.net Wed Oct 9 00:00:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 16:00:29 -0700 Subject: [Patches] [ python-Patches-616496 ] textwrap: prefix short lines Message-ID: Patches item #616496, was opened at 2002-09-30 07:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=616496&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Greg Ward (gward) Summary: textwrap: prefix short lines Initial Comment: If the text to be filled is shorter than one line, initial_indent is not prefixed to the resulting text. For example: >>> textwrap.fill('abc '*18, initial_indent=6*' ') ' abc abc abc abc ... abc\nabc abc' >>> textwrap.fill('abc '*10, initial_indent=6*' ') 'abc abc abc abc abc abc abc abc abc abc ' >>> I believe the attached patch fixes this. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-08 19:00 Message: Logged In: YES user_id=33168 Guido checked in textwrap.py 1.16 which fixed this problem. Closing this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=616496&group_id=5470 From noreply@sourceforge.net Wed Oct 9 00:04:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 16:04:54 -0700 Subject: [Patches] [ python-Patches-614596 ] fix for urllib2.AbstractBasicAuthHandler Message-ID: Patches item #614596, was opened at 2002-09-25 15:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614596&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Williams (johnw42) >Assigned to: Jeremy Hylton (jhylton) Summary: fix for urllib2.AbstractBasicAuthHandler Initial Comment: This one-line patch fixes the authentication in urllib2 by making a regex case-insensitive. I don't know if this is "correct" HTTP behavior, but at last one web site (www.lexis.com) has a "Realm=" field in the www-authenticate header, causing the current version to fail. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-08 19:04 Message: Logged In: YES user_id=33168 Assigning to Jeremy, if this is correct, I can check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614596&group_id=5470 From noreply@sourceforge.net Wed Oct 9 14:20:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 06:20:25 -0700 Subject: [Patches] [ python-Patches-617311 ] Tiny profiling info (Psyco #2) Message-ID: Patches item #617311, was opened at 2002-10-01 23:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617311&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Michael Hudson (mwh) Summary: Tiny profiling info (Psyco #2) Initial Comment: Psyco-friendly patch #2. A very very small statistic-collecting patch. pystate.h: added a field at the end of the PyThreadStruct: int tick_counter; ceval.c: eval_frame(): tstate->tick_counter is incremented whenever the check_interval ticker reaches zero. The purpose is to give a useful measure of the number of interpreted bytecode instructions in a given thread. This extremely lightweight statistic collector can be of interest to profilers (like psyco.jit()). We can safely guess that a single integer increment every 100 interpreted bytecode instructions will go entierely unnoticed in any performance measure. [This is true for pystone.py.] ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2002-10-09 13:20 Message: Logged In: YES user_id=4771 Attached an updated diff for 2.3. This one doesn't have Windows line endings and includes the initialization of tick_counter to 0 that was added by Guido in the latest 2.2.2. (I thought it was unnecessary to initialize it to anything because profilers would only be interested in differences.) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-07 14:17 Message: Logged In: YES user_id=4771 Uploaded the 2.3 patch (this one cleanly generated -- for the other one I just cat'ed two patches in one). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-07 09:42 Message: Logged In: YES user_id=6656 Done in Include/pystate.h revision 2.18.16.1 Python/ceval.c revision 2.301.4.7 Armin, I don't know how you generated this patch, but it would have been easier to apply if it had been rooted in the "src" directory, like e.g.: $ cvs diff Include/pystate.h Python/ceval.c > ~/diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-06 20:45 Message: Logged In: YES user_id=6380 I'd like to get this into 2.2.2. MWH, can you check it in? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-04 14:36 Message: Logged In: YES user_id=4771 It is the only way I could work out so far that can "predict" how much a function will be accelerated when run under Psyco. This is a very precious indication for an automatic Psyco-binder. The following table shows the results with the various test functions of the distribution's "test.py" file: (fn name) (speed-up) (bytecode insns per second) f1 106.00 2310545 f4 11.33 2819100 f5 12.08 2992445 f6 1.35 412022 f7 2.24 1331353 f7bis 10.29 1632296 The third column is '(tick_counter * check_interval) / execution_time'. The correlation between the two columns is admittedly not perfect, but still we can see that it was not worthy to try and accelerate f6 because it didn't spend a lot of time actually interpreting bytecodes. Note that similar information could be obtained by setting a line-tracing hook, counting not instructions but lines (which is less precise but still a good approximation). However, line tracing is *much* too slow for anything but debugging usage. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-04 10:42 Message: Logged In: YES user_id=6656 I see no harm in this. Are you sure it's actually going to be useful, though? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617311&group_id=5470 From noreply@sourceforge.net Wed Oct 9 16:17:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 08:17:00 -0700 Subject: [Patches] [ python-Patches-510695 ] cycle profiler for VM opcodes Message-ID: Patches item #510695, was opened at 2002-01-30 13:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=510695&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None >Priority: 1 Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: cycle profiler for VM opcodes Initial Comment: This is just some code I'm noodling around with. It counts the number of cycles each Python VM opcode takes to execute, using the Pentium timestamp counter. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-10-09 15:16 Message: Logged In: YES user_id=31392 sure ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 21:12 Message: Logged In: YES user_id=21627 Is this still of relevance? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=510695&group_id=5470 From noreply@sourceforge.net Wed Oct 9 16:19:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 08:19:31 -0700 Subject: [Patches] [ python-Patches-614596 ] fix for urllib2.AbstractBasicAuthHandler Message-ID: Patches item #614596, was opened at 2002-09-25 19:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614596&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Williams (johnw42) >Assigned to: Neal Norwitz (nnorwitz) Summary: fix for urllib2.AbstractBasicAuthHandler Initial Comment: This one-line patch fixes the authentication in urllib2 by making a regex case-insensitive. I don't know if this is "correct" HTTP behavior, but at last one web site (www.lexis.com) has a "Realm=" field in the www-authenticate header, causing the current version to fail. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-10-09 15:19 Message: Logged In: YES user_id=31392 fine by me ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-08 23:04 Message: Logged In: YES user_id=33168 Assigning to Jeremy, if this is correct, I can check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614596&group_id=5470 From noreply@sourceforge.net Thu Oct 10 00:17:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 16:17:15 -0700 Subject: [Patches] [ python-Patches-614596 ] fix for urllib2.AbstractBasicAuthHandler Message-ID: Patches item #614596, was opened at 2002-09-25 15:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614596&group_id=5470 Category: Library (Lib) >Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: John Williams (johnw42) Assigned to: Neal Norwitz (nnorwitz) Summary: fix for urllib2.AbstractBasicAuthHandler Initial Comment: This one-line patch fixes the authentication in urllib2 by making a regex case-insensitive. I don't know if this is "correct" HTTP behavior, but at last one web site (www.lexis.com) has a "Realm=" field in the www-authenticate header, causing the current version to fail. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-09 19:17 Message: Logged In: YES user_id=33168 Thanks! Checked in as urllib2.py 1.35 ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-09 11:19 Message: Logged In: YES user_id=31392 fine by me ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-08 19:04 Message: Logged In: YES user_id=33168 Assigning to Jeremy, if this is correct, I can check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614596&group_id=5470 From noreply@sourceforge.net Thu Oct 10 00:19:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 16:19:55 -0700 Subject: [Patches] [ python-Patches-586437 ] galeon support in webbrowser Message-ID: Patches item #586437, was opened at 2002-07-25 08:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=586437&group_id=5470 Category: Library (Lib) Group: Python 2.2.x >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Supreet Sethi (supreet) Assigned to: Nobody/Anonymous (nobody) Summary: galeon support in webbrowser Initial Comment: adds galeon support to webbrowser.py ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-09 19:19 Message: Logged In: YES user_id=33168 Closing this patch. It is very similar to 585913. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-26 14:55 Message: Logged In: YES user_id=21627 How does this relate to https://sourceforge.net/tracker/index.php?func=detail&aid=585913&group_id=5470&atid=305470 ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=586437&group_id=5470 From noreply@sourceforge.net Thu Oct 10 00:35:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 16:35:20 -0700 Subject: [Patches] [ python-Patches-585913 ] Adds Galeon support to webbrowser.py Message-ID: Patches item #585913, was opened at 2002-07-24 09:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=585913&group_id=5470 Category: Library (Lib) >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Copeland (oracle) >Assigned to: Martin v. Löwis (loewis) Summary: Adds Galeon support to webbrowser.py Initial Comment: Simple context diff against current CVS tree to add support for Galeon to webbrowser.py ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-09 19:35 Message: Logged In: YES user_id=33168 Martin, I've closed the other (duplicate) patch. I've attached a new patch here with a few cleanups. I manually tested that this works with galeon. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-12 19:48 Message: Logged In: YES user_id=21627 If the patch has been accepted, its Resolution will be set to accepted, and SF will send you a message - so no, it hasn't been accepted yet. I still haven't found the time to compare the two patches, and nobody else has presented any clear analysis of the relative qualities, so I still don't know which one to accept - apparently, nobody else has looked at them, either. ---------------------------------------------------------------------- Comment By: Greg Copeland (oracle) Date: 2002-08-12 14:12 Message: Logged In: YES user_id=40173 Has then patch been accepted? What's the standard why of letting people know if a patch has been accepted or rejected? ---------------------------------------------------------------------- Comment By: Greg Copeland (oracle) Date: 2002-07-26 15:56 Message: Logged In: YES user_id=40173 Not really sure. I assume it's just a second patch by another author. What can I say, day late and a dollar short. ;) Having looked at the other patch, it appears mine is a little more well rounded/complete/feature rich, if only slightly. I invite you to take a look for your self. I'm also not sure what version of webbrowser.py the other patch is against. My patch is against the CVS version so it will be a breeze to apply. Enjoy! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-26 14:54 Message: Logged In: YES user_id=21627 How does this relate to https://sourceforge.net/tracker/index.php?func=detail&aid=586437&group_id=5470&atid=305470 ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=585913&group_id=5470 From noreply@sourceforge.net Thu Oct 10 00:43:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 16:43:06 -0700 Subject: [Patches] [ python-Patches-613605 ] Bugfix: content-type header parsing Message-ID: Patches item #613605, was opened at 2002-09-24 02:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613605&group_id=5470 Category: Demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Funk (pefu) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Bugfix: content-type header parsing Initial Comment: webchecker.py stumbles on content-type: text/html; charset=iso8859-1 This patch should fix it. Discovery is courtesy of Maik Jablonski, who posted an initial fix on the german zope user group mailing list (zope at dzug.org). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-09 19:43 Message: Logged In: YES user_id=33168 This makes sense to me. Fred, assign back to me if you want me to check in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613605&group_id=5470 From noreply@sourceforge.net Thu Oct 10 09:44:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 01:44:34 -0700 Subject: [Patches] [ python-Patches-585913 ] Adds Galeon support to webbrowser.py Message-ID: Patches item #585913, was opened at 2002-07-24 15:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=585913&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Greg Copeland (oracle) >Assigned to: Neal Norwitz (nnorwitz) Summary: Adds Galeon support to webbrowser.py Initial Comment: Simple context diff against current CVS tree to add support for Galeon to webbrowser.py ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 10:44 Message: Logged In: YES user_id=21627 Neal, thanks for testing it. This is all this patch has been waiting for, so please apply it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-10 01:35 Message: Logged In: YES user_id=33168 Martin, I've closed the other (duplicate) patch. I've attached a new patch here with a few cleanups. I manually tested that this works with galeon. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-13 01:48 Message: Logged In: YES user_id=21627 If the patch has been accepted, its Resolution will be set to accepted, and SF will send you a message - so no, it hasn't been accepted yet. I still haven't found the time to compare the two patches, and nobody else has presented any clear analysis of the relative qualities, so I still don't know which one to accept - apparently, nobody else has looked at them, either. ---------------------------------------------------------------------- Comment By: Greg Copeland (oracle) Date: 2002-08-12 20:12 Message: Logged In: YES user_id=40173 Has then patch been accepted? What's the standard why of letting people know if a patch has been accepted or rejected? ---------------------------------------------------------------------- Comment By: Greg Copeland (oracle) Date: 2002-07-26 21:56 Message: Logged In: YES user_id=40173 Not really sure. I assume it's just a second patch by another author. What can I say, day late and a dollar short. ;) Having looked at the other patch, it appears mine is a little more well rounded/complete/feature rich, if only slightly. I invite you to take a look for your self. I'm also not sure what version of webbrowser.py the other patch is against. My patch is against the CVS version so it will be a breeze to apply. Enjoy! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-26 20:54 Message: Logged In: YES user_id=21627 How does this relate to https://sourceforge.net/tracker/index.php?func=detail&aid=586437&group_id=5470&atid=305470 ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=585913&group_id=5470 From noreply@sourceforge.net Thu Oct 10 10:01:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 02:01:33 -0700 Subject: [Patches] [ python-Patches-621205 ] Tkinter updates for tk8.4 Message-ID: Patches item #621205, was opened at 2002-10-10 09:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621205&group_id=5470 Category: Tkinter Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Martin Franklin (mfranklin1) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter updates for tk8.4 Initial Comment: This patch includes three new widgets : PanedWindow, Spinbox and LabelFrame I have also added the edit_* methods to the Text widget It requires tk 8.4 but should not fall over on earlier versions (provided the end user does not use these options) I've uploaded a diff -c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621205&group_id=5470 From noreply@sourceforge.net Thu Oct 10 14:03:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 06:03:23 -0700 Subject: [Patches] [ python-Patches-580869 ] Fix for seg fault on test_re on mac osx Message-ID: Patches item #580869, was opened at 2002-07-12 23:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 Category: Tests >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven D. Majewski (sdm7g) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Fix for seg fault on test_re on mac osx Initial Comment: import resource soft, hard = resource.getrlimit( resource.RLIMIT_STACK ) resource.setrlimit( resource.RLIMIT_STACK, (1024 * 2048, hard)) is the python equivalent of the tcsh 'limit stack 2048' and will keep python from seg faulting on test_re . ( maybe wrapped in a "if os.platform == 'darwin' : " -- are there any other systems that have this problem ? ) -- Steve Majewski ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 From noreply@sourceforge.net Thu Oct 10 14:30:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 06:30:21 -0700 Subject: [Patches] [ python-Patches-585913 ] Adds Galeon support to webbrowser.py Message-ID: Patches item #585913, was opened at 2002-07-24 08:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=585913&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Greg Copeland (oracle) Assigned to: Neal Norwitz (nnorwitz) Summary: Adds Galeon support to webbrowser.py Initial Comment: Simple context diff against current CVS tree to add support for Galeon to webbrowser.py ---------------------------------------------------------------------- Comment By: Greg Copeland (oracle) Date: 2002-10-10 08:30 Message: Logged In: YES user_id=40173 Ya thanks for cleaning it up. After I submitted the patch, I realized that I had left some print statements hanging around. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 03:44 Message: Logged In: YES user_id=21627 Neal, thanks for testing it. This is all this patch has been waiting for, so please apply it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-09 18:35 Message: Logged In: YES user_id=33168 Martin, I've closed the other (duplicate) patch. I've attached a new patch here with a few cleanups. I manually tested that this works with galeon. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-12 18:48 Message: Logged In: YES user_id=21627 If the patch has been accepted, its Resolution will be set to accepted, and SF will send you a message - so no, it hasn't been accepted yet. I still haven't found the time to compare the two patches, and nobody else has presented any clear analysis of the relative qualities, so I still don't know which one to accept - apparently, nobody else has looked at them, either. ---------------------------------------------------------------------- Comment By: Greg Copeland (oracle) Date: 2002-08-12 13:12 Message: Logged In: YES user_id=40173 Has then patch been accepted? What's the standard why of letting people know if a patch has been accepted or rejected? ---------------------------------------------------------------------- Comment By: Greg Copeland (oracle) Date: 2002-07-26 14:56 Message: Logged In: YES user_id=40173 Not really sure. I assume it's just a second patch by another author. What can I say, day late and a dollar short. ;) Having looked at the other patch, it appears mine is a little more well rounded/complete/feature rich, if only slightly. I invite you to take a look for your self. I'm also not sure what version of webbrowser.py the other patch is against. My patch is against the CVS version so it will be a breeze to apply. Enjoy! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-26 13:54 Message: Logged In: YES user_id=21627 How does this relate to https://sourceforge.net/tracker/index.php?func=detail&aid=586437&group_id=5470&atid=305470 ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=585913&group_id=5470 From noreply@sourceforge.net Thu Oct 10 15:28:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 07:28:50 -0700 Subject: [Patches] [ python-Patches-569139 ] Implementation of major, minor and makedev Message-ID: Patches item #569139, was opened at 2002-06-14 20:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=569139&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Martin v. Löwis (loewis) Summary: Implementation of major, minor and makedev Initial Comment: As discussed in python-dev, st_rdev provides an integer, which usually needs to be translated in a (major, minor) pair before it's useful. There are no implementations of major() and minor() in the current library, and maybe there shouldn't be, since their functionality is not portable. This patch provides a portable way to access this information, by providing a new attribute to the os.stat() return tuple named st_rdev_pair. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 16:28 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as configure 1.345; configure.in 1.356; pyconfig.h.in 1.53; libos.tex 1.98; posixmodule.c 2.265; ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-08 21:17 Message: Logged In: YES user_id=33168 I'm fine with checking in. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 23:48 Message: Logged In: YES user_id=21627 Is anything stopping this patch? If not, I'll apply it. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-06-15 21:04 Message: Logged In: YES user_id=7887 I'm not sure if that's really the right way to implement the needed features for tarfile. Maybe including major, minor, and makedev could be the way to go. I'm sending the rationale to python-dev for discussion, and attaching a new patch with their implementations, instead of st_rdev_pair. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-06-15 00:23 Message: Logged In: YES user_id=7887 I'll redo the patch with a test. Thanks! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-15 00:02 Message: Logged In: YES user_id=33168 You are correct about the DECREF, it is not necessary. I'm not sure if any standards define major/minor (that's why I asked). What platform(s) did you test on? ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-06-14 23:47 Message: Logged In: YES user_id=7887 I don't think a test is needed. If st_rdev is available, this information must be decodable by the system, and this is done by the major/minor pair, AFAIK. About the DECREF, I don't think it's needed. w's reference is stolen by v when PyStructSequence_SET_ITEM is run, and will be destroyed with v once it's DECREF'd. If that's not true, the whole logic is wrong in that function. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-14 23:36 Message: Logged In: YES user_id=33168 Are major/minor guaranteed to exist? Should a check be added to configure? There is a missing DECREF. In the last line of the patch to posixmodule.c, there is if (PyErr_Occurred()) { In that block, w needs to be DECREFed. You can initialize w = NULL in the declaration, then do an XDECREF in the error block. That way you don't need to handle the error creating w, if w != NULL, set the items in the tuple. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=569139&group_id=5470 From noreply@sourceforge.net Thu Oct 10 15:37:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 07:37:06 -0700 Subject: [Patches] [ python-Patches-612602 ] "Bare" text tag_configure in Tkinter Message-ID: Patches item #612602, was opened at 2002-09-21 20:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612602&group_id=5470 Category: Tkinter Group: Python 2.1.2 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Steve Reeves (sreeves) Assigned to: Martin v. Löwis (loewis) >Summary: "Bare" text tag_configure in Tkinter Initial Comment: In Tcl/Tk, doing a "tag configure" operation on a text widget with only a tag name as argument returns all of the attributes configured for that tag. The analogous tag_configure method in Tkinter returns nothing. The attached patch fixes this. I'm using Python 2.1, but the same bug is in 2.2 as well. Here is a typescript showing the results of the analogous commands in Tcl/Tk and Tkinter: $ wish % text .t .t % .t tag configure someTag -foreground red % .t tag configure someTag -foreground -foreground {} {} {} red % .t tag configure someTag {-background {} {} {} {}} {-bgstipple {} {} {} {}} {-borderwidth {} {} 0 {}} {-elide {} {} 0 {}} {-fgstipple {} {} {} {}} {-font {} {} {} {}} {-foreground {} {} {} red} {-justify {} {} {} {}} {-lmargin1 {} {} {} {}} {-lmargin2 {} {} {} {}} {-offset {} {} {} {}} {-overstrike {} {} {} {}} {-relief {} {} {} {}} {-rmargin {} {} {} {}} {-spacing1 {} {} {} {}} {-spacing2 {} {} {} {}} {-spacing3 {} {} {} {}} {-tabs {} {} {} {}} {-underline {} {} {} {}} {-wrap {} {} {} {}} % ^D $ python Python 2.1.3 (#1, Sep 7 2002, 15:29:56) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import Tkinter >>> root = Tkinter.Tk() >>> t = Tkinter.Text(root) >>> t.tag_configure('someTag', foreground='red') >>> t.tag_configure('someTag', 'foreground') ('foreground', '', '', '', 'red') >>> t.tag_configure('someTag') >>> ^D $ ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 16:37 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as Tkinter.py 1.164; ACKS 1.208; NEWS 1.497; ---------------------------------------------------------------------- Comment By: Steve Reeves (sreeves) Date: 2002-09-23 21:11 Message: Logged In: YES user_id=2647 Here is a revised patch that generalizes configure() into a new internal function _configure(). This is then used by Misc.configure, Canvas.itemconfigure, Listbox.itemconfigure, Menu.entryconfigure, Text.image_configure, Text.tag_configure and Text.window_configure. BTW, the Text widget's image_configure and window_configure had the same bug as tag_configure in not returning anything for a "bare" call. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 13:34 Message: Logged In: YES user_id=21627 So would you like to produce a new patch in that direction? ---------------------------------------------------------------------- Comment By: Steve Reeves (sreeves) Date: 2002-09-21 23:38 Message: Logged In: YES user_id=2647 Oops, yeah, it should return a dictionary. Now I also see the comment in configure() about generalizing it so tag_configure() can use it too. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-21 22:35 Message: Logged In: YES user_id=21627 I may be missing something, but shouldn't tag_configure return a dictionary in this case? See the widget's configure for comparison. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612602&group_id=5470 From noreply@sourceforge.net Thu Oct 10 15:46:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 07:46:07 -0700 Subject: [Patches] [ python-Patches-621205 ] Tkinter updates for tk8.4 Message-ID: Patches item #621205, was opened at 2002-10-10 11:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621205&group_id=5470 Category: Tkinter Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Martin Franklin (mfranklin1) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter updates for tk8.4 Initial Comment: This patch includes three new widgets : PanedWindow, Spinbox and LabelFrame I have also added the edit_* methods to the Text widget It requires tk 8.4 but should not fall over on earlier versions (provided the end user does not use these options) I've uploaded a diff -c ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 16:46 Message: Logged In: YES user_id=21627 Which version of the patch is the correct one? There is no need to test the Tcl version when wrapping new Tcl features: as long as Tkinter continues to import correctly on older Tk versions, it is fine that invoking the newer wrappers will cause Tcl errors. What are the pathName comment lines? Please don't add that many blank lines. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621205&group_id=5470 From noreply@sourceforge.net Thu Oct 10 16:02:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 08:02:40 -0700 Subject: [Patches] [ python-Patches-621205 ] Tkinter updates for tk8.4 Message-ID: Patches item #621205, was opened at 2002-10-10 09:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621205&group_id=5470 Category: Tkinter Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Martin Franklin (mfranklin1) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter updates for tk8.4 Initial Comment: This patch includes three new widgets : PanedWindow, Spinbox and LabelFrame I have also added the edit_* methods to the Text widget It requires tk 8.4 but should not fall over on earlier versions (provided the end user does not use these options) I've uploaded a diff -c ---------------------------------------------------------------------- >Comment By: Martin Franklin (mfranklin1) Date: 2002-10-10 15:02 Message: Logged In: YES user_id=482545 The second patch (2002-10-10 09:18) is (was) the correct version I will upload a new one with your comments in mind. The test for Tcl version was commented out to get a response (and it did!) so I will remove it. The pathName comments should have been removed and will be soon (as will the blank lines) I have also gone on and added a few comments to the Button and Label widget (these now support the -compound option) and I have updated the module comment at the top of the module to include the new Widgets so pydoc can pick them up. The Wm class has sprung a new method I can't find any more updates on the tcl tk site... but there may be some small ones.... I would be interested in your comments on the style of the doc strings for the new widgets. Basically I have cut and pasted from the tk command reference pages (with a few light edits) This means they are different from the older widgets ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 14:46 Message: Logged In: YES user_id=21627 Which version of the patch is the correct one? There is no need to test the Tcl version when wrapping new Tcl features: as long as Tkinter continues to import correctly on older Tk versions, it is fine that invoking the newer wrappers will cause Tcl errors. What are the pathName comment lines? Please don't add that many blank lines. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621205&group_id=5470 From noreply@sourceforge.net Thu Oct 10 16:57:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 08:57:40 -0700 Subject: [Patches] [ python-Patches-580869 ] Fix for seg fault on test_re on mac osx Message-ID: Patches item #580869, was opened at 2002-07-12 22:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven D. Majewski (sdm7g) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Fix for seg fault on test_re on mac osx Initial Comment: import resource soft, hard = resource.getrlimit( resource.RLIMIT_STACK ) resource.setrlimit( resource.RLIMIT_STACK, (1024 * 2048, hard)) is the python equivalent of the tcsh 'limit stack 2048' and will keep python from seg faulting on test_re . ( maybe wrapped in a "if os.platform == 'darwin' : " -- are there any other systems that have this problem ? ) -- Steve Majewski ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 10:57 Message: Logged In: YES user_id=44345 I tried adding the above code to regrtest.py. When I tried to run python regrtest.py test_re I got a ValueError exception: "not allowed to raise maximum limit". I have no trouble using the ulimit builtin command to raise my stack size. Steve, were you perhaps running as root when you tried this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 From noreply@sourceforge.net Thu Oct 10 17:00:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 09:00:29 -0700 Subject: [Patches] [ python-Patches-580869 ] Fix for seg fault on test_re on mac osx Message-ID: Patches item #580869, was opened at 2002-07-12 22:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven D. Majewski (sdm7g) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Fix for seg fault on test_re on mac osx Initial Comment: import resource soft, hard = resource.getrlimit( resource.RLIMIT_STACK ) resource.setrlimit( resource.RLIMIT_STACK, (1024 * 2048, hard)) is the python equivalent of the tcsh 'limit stack 2048' and will keep python from seg faulting on test_re . ( maybe wrapped in a "if os.platform == 'darwin' : " -- are there any other systems that have this problem ? ) -- Steve Majewski ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 11:00 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 10:57 Message: Logged In: YES user_id=44345 I tried adding the above code to regrtest.py. When I tried to run python regrtest.py test_re I got a ValueError exception: "not allowed to raise maximum limit". I have no trouble using the ulimit builtin command to raise my stack size. Steve, were you perhaps running as root when you tried this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 From noreply@sourceforge.net Thu Oct 10 17:01:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 09:01:10 -0700 Subject: [Patches] [ python-Patches-580869 ] Fix for seg fault on test_re on mac osx Message-ID: Patches item #580869, was opened at 2002-07-12 22:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven D. Majewski (sdm7g) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Fix for seg fault on test_re on mac osx Initial Comment: import resource soft, hard = resource.getrlimit( resource.RLIMIT_STACK ) resource.setrlimit( resource.RLIMIT_STACK, (1024 * 2048, hard)) is the python equivalent of the tcsh 'limit stack 2048' and will keep python from seg faulting on test_re . ( maybe wrapped in a "if os.platform == 'darwin' : " -- are there any other systems that have this problem ? ) -- Steve Majewski ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 11:01 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 11:00 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 10:57 Message: Logged In: YES user_id=44345 I tried adding the above code to regrtest.py. When I tried to run python regrtest.py test_re I got a ValueError exception: "not allowed to raise maximum limit". I have no trouble using the ulimit builtin command to raise my stack size. Steve, were you perhaps running as root when you tried this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 From noreply@sourceforge.net Thu Oct 10 17:01:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 09:01:31 -0700 Subject: [Patches] [ python-Patches-580869 ] Fix for seg fault on test_re on mac osx Message-ID: Patches item #580869, was opened at 2002-07-12 22:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven D. Majewski (sdm7g) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Fix for seg fault on test_re on mac osx Initial Comment: import resource soft, hard = resource.getrlimit( resource.RLIMIT_STACK ) resource.setrlimit( resource.RLIMIT_STACK, (1024 * 2048, hard)) is the python equivalent of the tcsh 'limit stack 2048' and will keep python from seg faulting on test_re . ( maybe wrapped in a "if os.platform == 'darwin' : " -- are there any other systems that have this problem ? ) -- Steve Majewski ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 11:01 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 11:01 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 11:00 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 10:57 Message: Logged In: YES user_id=44345 I tried adding the above code to regrtest.py. When I tried to run python regrtest.py test_re I got a ValueError exception: "not allowed to raise maximum limit". I have no trouble using the ulimit builtin command to raise my stack size. Steve, were you perhaps running as root when you tried this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 From noreply@sourceforge.net Thu Oct 10 17:04:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 09:04:15 -0700 Subject: [Patches] [ python-Patches-580869 ] Fix for seg fault on test_re on mac osx Message-ID: Patches item #580869, was opened at 2002-07-12 22:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven D. Majewski (sdm7g) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Fix for seg fault on test_re on mac osx Initial Comment: import resource soft, hard = resource.getrlimit( resource.RLIMIT_STACK ) resource.setrlimit( resource.RLIMIT_STACK, (1024 * 2048, hard)) is the python equivalent of the tcsh 'limit stack 2048' and will keep python from seg faulting on test_re . ( maybe wrapped in a "if os.platform == 'darwin' : " -- are there any other systems that have this problem ? ) -- Steve Majewski ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 11:04 Message: Logged In: YES user_id=44345 Sorry for the bogus updates. Opera 6.0 Beta 1 apparently has file upload problems. Resorting to IE... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 11:01 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 11:01 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 11:00 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 10:57 Message: Logged In: YES user_id=44345 I tried adding the above code to regrtest.py. When I tried to run python regrtest.py test_re I got a ValueError exception: "not allowed to raise maximum limit". I have no trouble using the ulimit builtin command to raise my stack size. Steve, were you perhaps running as root when you tried this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 From noreply@sourceforge.net Thu Oct 10 18:09:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 10:09:01 -0700 Subject: [Patches] [ python-Patches-621205 ] Tkinter updates for tk8.4 Message-ID: Patches item #621205, was opened at 2002-10-10 11:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621205&group_id=5470 Category: Tkinter Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Martin Franklin (mfranklin1) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter updates for tk8.4 Initial Comment: This patch includes three new widgets : PanedWindow, Spinbox and LabelFrame I have also added the edit_* methods to the Text widget It requires tk 8.4 but should not fall over on earlier versions (provided the end user does not use these options) I've uploaded a diff -c ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 19:09 Message: Logged In: YES user_id=21627 The text of the doc strings is all fine; as you know, they ought to be in inidicative form (or is it imperative?). However, please separate the first sentence from the following ones by an empty line. This allows interactive tools to print a tooltip. ---------------------------------------------------------------------- Comment By: Martin Franklin (mfranklin1) Date: 2002-10-10 17:02 Message: Logged In: YES user_id=482545 The second patch (2002-10-10 09:18) is (was) the correct version I will upload a new one with your comments in mind. The test for Tcl version was commented out to get a response (and it did!) so I will remove it. The pathName comments should have been removed and will be soon (as will the blank lines) I have also gone on and added a few comments to the Button and Label widget (these now support the -compound option) and I have updated the module comment at the top of the module to include the new Widgets so pydoc can pick them up. The Wm class has sprung a new method I can't find any more updates on the tcl tk site... but there may be some small ones.... I would be interested in your comments on the style of the doc strings for the new widgets. Basically I have cut and pasted from the tk command reference pages (with a few light edits) This means they are different from the older widgets ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 16:46 Message: Logged In: YES user_id=21627 Which version of the patch is the correct one? There is no need to test the Tcl version when wrapping new Tcl features: as long as Tkinter continues to import correctly on older Tk versions, it is fine that invoking the newer wrappers will cause Tcl errors. What are the pathName comment lines? Please don't add that many blank lines. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621205&group_id=5470 From noreply@sourceforge.net Thu Oct 10 18:11:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 10:11:12 -0700 Subject: [Patches] [ python-Patches-580869 ] Fix for seg fault on test_re on mac osx Message-ID: Patches item #580869, was opened at 2002-07-12 23:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven D. Majewski (sdm7g) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Fix for seg fault on test_re on mac osx Initial Comment: import resource soft, hard = resource.getrlimit( resource.RLIMIT_STACK ) resource.setrlimit( resource.RLIMIT_STACK, (1024 * 2048, hard)) is the python equivalent of the tcsh 'limit stack 2048' and will keep python from seg faulting on test_re . ( maybe wrapped in a "if os.platform == 'darwin' : " -- are there any other systems that have this problem ? ) -- Steve Majewski ---------------------------------------------------------------------- >Comment By: Steven D. Majewski (sdm7g) Date: 2002-10-10 13:11 Message: Logged In: YES user_id=105602 NOT running as root -- I just tried it again and verified that it works for me. HOWEVER: I haven't yet upgraded to Jaguar/10.2 Maybe that's the difference ? I can post a request on the pythonmac list and ask some others to try it and find out if it's a 10.1.x vs 10.2 thing. -- Steve ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 12:04 Message: Logged In: YES user_id=44345 Sorry for the bogus updates. Opera 6.0 Beta 1 apparently has file upload problems. Resorting to IE... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 12:01 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 12:01 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 12:00 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 11:57 Message: Logged In: YES user_id=44345 I tried adding the above code to regrtest.py. When I tried to run python regrtest.py test_re I got a ValueError exception: "not allowed to raise maximum limit". I have no trouble using the ulimit builtin command to raise my stack size. Steve, were you perhaps running as root when you tried this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 From noreply@sourceforge.net Thu Oct 10 20:05:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 12:05:30 -0700 Subject: [Patches] [ python-Patches-580869 ] Fix for seg fault on test_re on mac osx Message-ID: Patches item #580869, was opened at 2002-07-12 23:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven D. Majewski (sdm7g) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Fix for seg fault on test_re on mac osx Initial Comment: import resource soft, hard = resource.getrlimit( resource.RLIMIT_STACK ) resource.setrlimit( resource.RLIMIT_STACK, (1024 * 2048, hard)) is the python equivalent of the tcsh 'limit stack 2048' and will keep python from seg faulting on test_re . ( maybe wrapped in a "if os.platform == 'darwin' : " -- are there any other systems that have this problem ? ) -- Steve Majewski ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-10 15:05 Message: Logged In: YES user_id=12800 I can verify the patch works on 10.1, specifically the OSX Server in the SF compile farm. ---------------------------------------------------------------------- Comment By: Steven D. Majewski (sdm7g) Date: 2002-10-10 13:11 Message: Logged In: YES user_id=105602 NOT running as root -- I just tried it again and verified that it works for me. HOWEVER: I haven't yet upgraded to Jaguar/10.2 Maybe that's the difference ? I can post a request on the pythonmac list and ask some others to try it and find out if it's a 10.1.x vs 10.2 thing. -- Steve ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 12:04 Message: Logged In: YES user_id=44345 Sorry for the bogus updates. Opera 6.0 Beta 1 apparently has file upload problems. Resorting to IE... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 12:01 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 12:01 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 12:00 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 11:57 Message: Logged In: YES user_id=44345 I tried adding the above code to regrtest.py. When I tried to run python regrtest.py test_re I got a ValueError exception: "not allowed to raise maximum limit". I have no trouble using the ulimit builtin command to raise my stack size. Steve, were you perhaps running as root when you tried this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 From noreply@sourceforge.net Thu Oct 10 20:32:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 12:32:23 -0700 Subject: [Patches] [ python-Patches-621205 ] Tkinter updates for tk8.4 Message-ID: Patches item #621205, was opened at 2002-10-10 09:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621205&group_id=5470 Category: Tkinter Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Martin Franklin (mfranklin1) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter updates for tk8.4 Initial Comment: This patch includes three new widgets : PanedWindow, Spinbox and LabelFrame I have also added the edit_* methods to the Text widget It requires tk 8.4 but should not fall over on earlier versions (provided the end user does not use these options) I've uploaded a diff -c ---------------------------------------------------------------------- >Comment By: Martin Franklin (mfranklin1) Date: 2002-10-10 19:32 Message: Logged In: YES user_id=482545 Done. I've uploaded the latest diff file. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 17:09 Message: Logged In: YES user_id=21627 The text of the doc strings is all fine; as you know, they ought to be in inidicative form (or is it imperative?). However, please separate the first sentence from the following ones by an empty line. This allows interactive tools to print a tooltip. ---------------------------------------------------------------------- Comment By: Martin Franklin (mfranklin1) Date: 2002-10-10 15:02 Message: Logged In: YES user_id=482545 The second patch (2002-10-10 09:18) is (was) the correct version I will upload a new one with your comments in mind. The test for Tcl version was commented out to get a response (and it did!) so I will remove it. The pathName comments should have been removed and will be soon (as will the blank lines) I have also gone on and added a few comments to the Button and Label widget (these now support the -compound option) and I have updated the module comment at the top of the module to include the new Widgets so pydoc can pick them up. The Wm class has sprung a new method I can't find any more updates on the tcl tk site... but there may be some small ones.... I would be interested in your comments on the style of the doc strings for the new widgets. Basically I have cut and pasted from the tk command reference pages (with a few light edits) This means they are different from the older widgets ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 14:46 Message: Logged In: YES user_id=21627 Which version of the patch is the correct one? There is no need to test the Tcl version when wrapping new Tcl features: as long as Tkinter continues to import correctly on older Tk versions, it is fine that invoking the newer wrappers will cause Tcl errors. What are the pathName comment lines? Please don't add that many blank lines. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621205&group_id=5470 From noreply@sourceforge.net Thu Oct 10 23:28:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 15:28:35 -0700 Subject: [Patches] [ python-Patches-580869 ] Fix for seg fault on test_re on mac osx Message-ID: Patches item #580869, was opened at 2002-07-13 05:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven D. Majewski (sdm7g) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Fix for seg fault on test_re on mac osx Initial Comment: import resource soft, hard = resource.getrlimit( resource.RLIMIT_STACK ) resource.setrlimit( resource.RLIMIT_STACK, (1024 * 2048, hard)) is the python equivalent of the tcsh 'limit stack 2048' and will keep python from seg faulting on test_re . ( maybe wrapped in a "if os.platform == 'darwin' : " -- are there any other systems that have this problem ? ) -- Steve Majewski ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2002-10-11 00:28 Message: Logged In: YES user_id=34209 I'd suggest adding a min(max, ) to the patch, so that it becomes: soft, hard = resource.getrlimit(resource.RLIMIT_STACK) newsoft = min(hard, max(soft, 1024*2048)) resource.setrlimit(resource.RLIMIT_STACK, newsoft, hard) And if the test suite only triggers this problem, doesn't it make more sense in s?re.py, as Fredrik suggested ? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-10 21:05 Message: Logged In: YES user_id=12800 I can verify the patch works on 10.1, specifically the OSX Server in the SF compile farm. ---------------------------------------------------------------------- Comment By: Steven D. Majewski (sdm7g) Date: 2002-10-10 19:11 Message: Logged In: YES user_id=105602 NOT running as root -- I just tried it again and verified that it works for me. HOWEVER: I haven't yet upgraded to Jaguar/10.2 Maybe that's the difference ? I can post a request on the pythonmac list and ask some others to try it and find out if it's a 10.1.x vs 10.2 thing. -- Steve ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 18:04 Message: Logged In: YES user_id=44345 Sorry for the bogus updates. Opera 6.0 Beta 1 apparently has file upload problems. Resorting to IE... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 18:01 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 18:01 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 18:00 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 17:57 Message: Logged In: YES user_id=44345 I tried adding the above code to regrtest.py. When I tried to run python regrtest.py test_re I got a ValueError exception: "not allowed to raise maximum limit". I have no trouble using the ulimit builtin command to raise my stack size. Steve, were you perhaps running as root when you tried this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 From noreply@sourceforge.net Thu Oct 10 23:38:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 15:38:25 -0700 Subject: [Patches] [ python-Patches-580869 ] Fix for seg fault on test_re on mac osx Message-ID: Patches item #580869, was opened at 2002-07-13 05:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven D. Majewski (sdm7g) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Fix for seg fault on test_re on mac osx Initial Comment: import resource soft, hard = resource.getrlimit( resource.RLIMIT_STACK ) resource.setrlimit( resource.RLIMIT_STACK, (1024 * 2048, hard)) is the python equivalent of the tcsh 'limit stack 2048' and will keep python from seg faulting on test_re . ( maybe wrapped in a "if os.platform == 'darwin' : " -- are there any other systems that have this problem ? ) -- Steve Majewski ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2002-10-11 00:38 Message: Logged In: YES user_id=34209 Oh, and the diff is kind of amusing. It seems to be MacBinary, but 'file' on my Debian machine isn't quite sure: /home/thomas/regrtest.diff: MacBinary III data with surprising version number Fortunately it's still readable :-) I guess I should go back to "cool with a Macintosh" too. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2002-10-11 00:28 Message: Logged In: YES user_id=34209 I'd suggest adding a min(max, ) to the patch, so that it becomes: soft, hard = resource.getrlimit(resource.RLIMIT_STACK) newsoft = min(hard, max(soft, 1024*2048)) resource.setrlimit(resource.RLIMIT_STACK, newsoft, hard) And if the test suite only triggers this problem, doesn't it make more sense in s?re.py, as Fredrik suggested ? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-10 21:05 Message: Logged In: YES user_id=12800 I can verify the patch works on 10.1, specifically the OSX Server in the SF compile farm. ---------------------------------------------------------------------- Comment By: Steven D. Majewski (sdm7g) Date: 2002-10-10 19:11 Message: Logged In: YES user_id=105602 NOT running as root -- I just tried it again and verified that it works for me. HOWEVER: I haven't yet upgraded to Jaguar/10.2 Maybe that's the difference ? I can post a request on the pythonmac list and ask some others to try it and find out if it's a 10.1.x vs 10.2 thing. -- Steve ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 18:04 Message: Logged In: YES user_id=44345 Sorry for the bogus updates. Opera 6.0 Beta 1 apparently has file upload problems. Resorting to IE... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 18:01 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 18:01 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 18:00 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 17:57 Message: Logged In: YES user_id=44345 I tried adding the above code to regrtest.py. When I tried to run python regrtest.py test_re I got a ValueError exception: "not allowed to raise maximum limit". I have no trouble using the ulimit builtin command to raise my stack size. Steve, were you perhaps running as root when you tried this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 From noreply@sourceforge.net Thu Oct 10 23:50:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 15:50:58 -0700 Subject: [Patches] [ python-Patches-585913 ] Adds Galeon support to webbrowser.py Message-ID: Patches item #585913, was opened at 2002-07-24 09:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=585913&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Greg Copeland (oracle) Assigned to: Neal Norwitz (nnorwitz) Summary: Adds Galeon support to webbrowser.py Initial Comment: Simple context diff against current CVS tree to add support for Galeon to webbrowser.py ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-10 18:50 Message: Logged In: YES user_id=33168 Checked in as Lib/webbrowser.py 1.33 ---------------------------------------------------------------------- Comment By: Greg Copeland (oracle) Date: 2002-10-10 09:30 Message: Logged In: YES user_id=40173 Ya thanks for cleaning it up. After I submitted the patch, I realized that I had left some print statements hanging around. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 04:44 Message: Logged In: YES user_id=21627 Neal, thanks for testing it. This is all this patch has been waiting for, so please apply it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-09 19:35 Message: Logged In: YES user_id=33168 Martin, I've closed the other (duplicate) patch. I've attached a new patch here with a few cleanups. I manually tested that this works with galeon. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-12 19:48 Message: Logged In: YES user_id=21627 If the patch has been accepted, its Resolution will be set to accepted, and SF will send you a message - so no, it hasn't been accepted yet. I still haven't found the time to compare the two patches, and nobody else has presented any clear analysis of the relative qualities, so I still don't know which one to accept - apparently, nobody else has looked at them, either. ---------------------------------------------------------------------- Comment By: Greg Copeland (oracle) Date: 2002-08-12 14:12 Message: Logged In: YES user_id=40173 Has then patch been accepted? What's the standard why of letting people know if a patch has been accepted or rejected? ---------------------------------------------------------------------- Comment By: Greg Copeland (oracle) Date: 2002-07-26 15:56 Message: Logged In: YES user_id=40173 Not really sure. I assume it's just a second patch by another author. What can I say, day late and a dollar short. ;) Having looked at the other patch, it appears mine is a little more well rounded/complete/feature rich, if only slightly. I invite you to take a look for your self. I'm also not sure what version of webbrowser.py the other patch is against. My patch is against the CVS version so it will be a breeze to apply. Enjoy! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-26 14:54 Message: Logged In: YES user_id=21627 How does this relate to https://sourceforge.net/tracker/index.php?func=detail&aid=586437&group_id=5470&atid=305470 ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=585913&group_id=5470 From noreply@sourceforge.net Thu Oct 10 23:52:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 15:52:38 -0700 Subject: [Patches] [ python-Patches-574750 ] Make python-mode.el use "jython" interp Message-ID: Patches item #574750, was opened at 2002-06-27 15:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=574750&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kevin J. Butler (kevinbutler) >Assigned to: Barry A. Warsaw (bwarsaw) >Summary: Make python-mode.el use "jython" interp Initial Comment: I believe it is time to start using the "jython" interpreter by default, rather than the "jpython" interpreter. This patch does it in a minimal way, just changing the command and acknowledging the two names. (I still prefer the JPython name, but...) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-28 12:00 Message: Logged In: YES user_id=21627 Please use context or unified diffs for patches; I'm attaching your change as a diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=574750&group_id=5470 From noreply@sourceforge.net Fri Oct 11 05:44:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 21:44:52 -0700 Subject: [Patches] [ python-Patches-555251 ] Mutable object change flag Message-ID: Patches item #555251, was opened at 2002-05-12 19:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=555251&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed Resolution: None Priority: 1 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Mutable object change flag Initial Comment: This patch is a proof-of-concept for marking state changes in mutable objects. It is meant as a simpler, faster alternative to a full built-in observer pattern. Here's the whole protocol: Mutable objects choosing to implement the protocol provide a writable attribute, cachevalid, which is initialized to zero. Upon any update to the object, the attribute is reset to zero. Callers who set the attribute to one can later check to see if an update has occurred (as indicated by a zero). >>> a = list('abcd') >>> a.cachevalid 0 >>> a.cachevalid=1 >>> a.cachevalid 1 >>> a[2] = 'k' >>> a.cachevalid 0 The proof-of-concept patch is implemented only for lists. A production version would need to include dictionaries. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 16:32 Message: Logged In: YES user_id=21627 Raymond, are you still interested in this approach? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=555251&group_id=5470 From noreply@sourceforge.net Fri Oct 11 06:38:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 22:38:32 -0700 Subject: [Patches] [ python-Patches-479898 ] Multibyte string on string::string_print Message-ID: Patches item #479898, was opened at 2001-11-09 08:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=479898&group_id=5470 Category: Core (C code) Group: None Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Multibyte string on string::string_print Initial Comment: Many multibyte language users are difficult to see native characters on list or dictionary and etc. This patch allows printing multibyte on UNIX98- compatible machines; mbtowc() is ISO/IEC 9899:1990 standard C-API function. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-11 07:38 Message: Logged In: YES user_id=21627 The patch was causing too many problems, so I had to back it out. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 15:58 Message: Logged In: YES user_id=21627 Thanks for the patch, committed as configure 1.343; configure.in 1.354; pyconfig.h.in 1.51; stringobject.c 2.190; I'm not quite sure that your correction is correct: If we invoke iswprint, cr is already guaranteed to be >0, since we otherwise goto nonprintable. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-10 04:38 Message: Logged In: YES user_id=55188 Oops, one mistake. sorry. stringobject.c:646 else if (_ISPRINT(c)) { -> else if (cr > 0 && _ISPRINT(c)) { (to detect whether mbtowc failed to convert) ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-10 04:26 Message: Logged In: YES user_id=55188 I uploaded 2nd patches which contains configure support. Unfortunately, Citrus(new generation locale support for *BSDs) didn't implemented iswprint() yet. but *BSDs supports wide character via Rune Locale isprint() func. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 14:21 Message: Logged In: YES user_id=6380 Still, the patch as it exists is unacceptable -- it needs configure support to decide whether to use mbtowc() and whether to use iswprint() or isprint() (I would hope on BSD there is also an iswprint(), to be standard-conforming). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-12-07 07:38 Message: Logged In: YES user_id=55188 Yes, it should be changed to iswprint on Linux systems. (but, isprint of BSD systems was designed for wide characters) As loewis told, EUC codes of Korea, Japan, Taiwan doesn't use 0x7F-0x9F for printable character. So, I think that using mbtowc is unavoidable. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-06 16:12 Message: Logged In: YES user_id=21627 You are right, the code should use iswprint instead. The point is that multiple subsequent bytes can make up a single printable character. Not every character above 127 is necessarily printable (e.g. in Latin-1, only characters above 160 are printable). Likewise, a single byte may not be printable, but a combination will print fine. So this code is supposed to catch only those cases where printing will actually work. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 20:08 Message: Logged In: YES user_id=6380 I don't understand the point of using mbtowc() here. The code extracts a wide character, but then it uses isprint() on it, and as far as I know, isprint() is not defined on wide characters, only on 'unsigned char' (and on -1). Isn't what the author wants simply to is isprint(c) instead of (c < ' ' || c >= 0x7f)??? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-09 22:21 Message: Logged In: YES user_id=21627 Even though I think this patch is correct in principle, I see a few problems with it: 1. Since it doesn't fix a bug, it probably cannot go into 2.2. 2. There is no autoconf test for mbtowc. You should test this in configure, and then conditionalize your code on HAVE_MBTOWC. 3. There is too much code duplication. Try to find a solution which special-cases the escape codes (\something) only once. For example, you may implement a trivial mbtowc redefinition if mbtowc is not available, and then use mbtowc always. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=479898&group_id=5470 From noreply@sourceforge.net Fri Oct 11 07:08:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 23:08:35 -0700 Subject: [Patches] [ python-Patches-621205 ] Tkinter updates for tk8.4 Message-ID: Patches item #621205, was opened at 2002-10-10 11:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621205&group_id=5470 Category: Tkinter Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Martin Franklin (mfranklin1) >Assigned to: Martin v. Löwis (loewis) Summary: Tkinter updates for tk8.4 Initial Comment: This patch includes three new widgets : PanedWindow, Spinbox and LabelFrame I have also added the edit_* methods to the Text widget It requires tk 8.4 but should not fall over on earlier versions (provided the end user does not use these options) I've uploaded a diff -c ---------------------------------------------------------------------- Comment By: Martin Franklin (mfranklin1) Date: 2002-10-10 21:32 Message: Logged In: YES user_id=482545 Done. I've uploaded the latest diff file. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 19:09 Message: Logged In: YES user_id=21627 The text of the doc strings is all fine; as you know, they ought to be in inidicative form (or is it imperative?). However, please separate the first sentence from the following ones by an empty line. This allows interactive tools to print a tooltip. ---------------------------------------------------------------------- Comment By: Martin Franklin (mfranklin1) Date: 2002-10-10 17:02 Message: Logged In: YES user_id=482545 The second patch (2002-10-10 09:18) is (was) the correct version I will upload a new one with your comments in mind. The test for Tcl version was commented out to get a response (and it did!) so I will remove it. The pathName comments should have been removed and will be soon (as will the blank lines) I have also gone on and added a few comments to the Button and Label widget (these now support the -compound option) and I have updated the module comment at the top of the module to include the new Widgets so pydoc can pick them up. The Wm class has sprung a new method I can't find any more updates on the tcl tk site... but there may be some small ones.... I would be interested in your comments on the style of the doc strings for the new widgets. Basically I have cut and pasted from the tk command reference pages (with a few light edits) This means they are different from the older widgets ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 16:46 Message: Logged In: YES user_id=21627 Which version of the patch is the correct one? There is no need to test the Tcl version when wrapping new Tcl features: as long as Tkinter continues to import correctly on older Tk versions, it is fine that invoking the newer wrappers will cause Tcl errors. What are the pathName comment lines? Please don't add that many blank lines. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621205&group_id=5470 From noreply@sourceforge.net Fri Oct 11 07:42:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 23:42:43 -0700 Subject: [Patches] [ python-Patches-580869 ] Fix for seg fault on test_re on mac osx Message-ID: Patches item #580869, was opened at 2002-07-12 23:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven D. Majewski (sdm7g) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Fix for seg fault on test_re on mac osx Initial Comment: import resource soft, hard = resource.getrlimit( resource.RLIMIT_STACK ) resource.setrlimit( resource.RLIMIT_STACK, (1024 * 2048, hard)) is the python equivalent of the tcsh 'limit stack 2048' and will keep python from seg faulting on test_re . ( maybe wrapped in a "if os.platform == 'darwin' : " -- are there any other systems that have this problem ? ) -- Steve Majewski ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-11 02:42 Message: Logged In: YES user_id=12800 Ok, I've added the Wouters Elaboration to regrtest.py and verified it works on both 10.1 and 10.2 (the former being the OSX machine on the SF compile farm and the latter being my home machine). Attached is the patch (I hope :). (Aside: why does this build `python' for 10.1 but `python.exe' for 10.2?) I think this patch is fine for Py2.2.2. Today Guido said he'd feel more comfortable with a patch to main.c than a patch to regrtest.py, s?re.py, or site.py (if I understood him correctly). However, I don't think there's time for that for Py2.2.2. Perhaps we should simply commit this simple fix so the test suite passes, and then work out a more comprehensive patch for Py2.3? Note that In addition, here is the output of the regrtest on 10.1 and 10.2. Is it worth spending time trying to fix these for the Py2.2.2 release? 10.1: 170 tests OK. 2 tests failed: test_fcntl test_largefile 21 tests skipped: test_al test_cd test_cl test_curses test_dl test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_minidom test_poll test_pyexpat test_sax test_socket_ssl test_socketserver test_sunaudiodev test_unicode_file test_winreg test_winsound 3 skips unexpected on darwin: test_sax test_pyexpat test_locale make: *** [test] Error 1 10.2: 171 tests OK. 1 test failed: test_locale 21 tests skipped: test_al test_cd test_cl test_curses test_dl test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_minidom test_nis test_poll test_pyexpat test_sax test_socket_ssl test_socketserver test_sunaudiodev test_unicode_file test_winreg test_winsound 2 skips unexpected on darwin: test_sax test_pyexpat ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2002-10-10 18:38 Message: Logged In: YES user_id=34209 Oh, and the diff is kind of amusing. It seems to be MacBinary, but 'file' on my Debian machine isn't quite sure: /home/thomas/regrtest.diff: MacBinary III data with surprising version number Fortunately it's still readable :-) I guess I should go back to "cool with a Macintosh" too. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2002-10-10 18:28 Message: Logged In: YES user_id=34209 I'd suggest adding a min(max, ) to the patch, so that it becomes: soft, hard = resource.getrlimit(resource.RLIMIT_STACK) newsoft = min(hard, max(soft, 1024*2048)) resource.setrlimit(resource.RLIMIT_STACK, newsoft, hard) And if the test suite only triggers this problem, doesn't it make more sense in s?re.py, as Fredrik suggested ? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-10 15:05 Message: Logged In: YES user_id=12800 I can verify the patch works on 10.1, specifically the OSX Server in the SF compile farm. ---------------------------------------------------------------------- Comment By: Steven D. Majewski (sdm7g) Date: 2002-10-10 13:11 Message: Logged In: YES user_id=105602 NOT running as root -- I just tried it again and verified that it works for me. HOWEVER: I haven't yet upgraded to Jaguar/10.2 Maybe that's the difference ? I can post a request on the pythonmac list and ask some others to try it and find out if it's a 10.1.x vs 10.2 thing. -- Steve ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 12:04 Message: Logged In: YES user_id=44345 Sorry for the bogus updates. Opera 6.0 Beta 1 apparently has file upload problems. Resorting to IE... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 12:01 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 12:01 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 12:00 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 11:57 Message: Logged In: YES user_id=44345 I tried adding the above code to regrtest.py. When I tried to run python regrtest.py test_re I got a ValueError exception: "not allowed to raise maximum limit". I have no trouble using the ulimit builtin command to raise my stack size. Steve, were you perhaps running as root when you tried this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 From noreply@sourceforge.net Fri Oct 11 08:23:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 00:23:17 -0700 Subject: [Patches] [ python-Patches-512981 ] readline /dev/tty problem Message-ID: Patches item #512981, was opened at 2002-02-04 13:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=512981&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Stutzbach (agthorr) Assigned to: Nobody/Anonymous (nobody) Summary: readline /dev/tty problem Initial Comment: GNU readline doesn't work if the C symbol "stdin" is not a tty, even if the python symbol sys.stdin is. This will happen, for example, if a program initially receives input from a pipe, but then changes sys.stdin to read from /dev/tty. (This is how programs like "less" work) Here's a sample program that exhibits this behavior: ------------------------------------------------------------------------ #!/usr/bin/env python import sys mail = sys.stdin.read () sys.stdin = open ('/dev/tty', 'r') import readline foo = raw_input ('add_idea> ') print foo ------------------------------------------------------------------------ You can test this by saving the above program to a file (foo.py), piping data to it, then trying to use GNU readline editing commands at the prompt. E.g.: ------------------------------------------------------------------------ liberty:~$ cat ideas.html | ./foo.py add_idea> asdfsdf^Afoo asdfsdffoo ------------------------------------------------------------------------ The patch attached seems to fix the problem. You may want to grep the source for other modules that may have similar bugs. Also, this patch assumes that the readline module is imported *after* sys.stdin is changed. This much better than nothing (particularly if it's documented), but there may be a better solution. -- Agthorr ---------------------------------------------------------------------- >Comment By: Daniel Stutzbach (agthorr) Date: 2002-10-11 00:23 Message: Logged In: YES user_id=6324 Okay, I've attached a new patch that works as you suggested. Let me know if you have any questions or concerns. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-08 02:27 Message: Logged In: YES user_id=21627 I think you should implement a strategy to detect changes to sys.stdin dynamically. For example, the old sys.stdin could go away, closing the file, which would leave readline with a garbage pointer. Instead, I think you should hold onto sys.stdin, and compare this reference from time to time with the current sys.stdin, and arrange to reinitialize readline (if possible). ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-10-07 14:32 Message: Logged In: YES user_id=6324 Yes, I'm interested in pursuing it. Let me know what I can do to move this along. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 14:15 Message: Logged In: YES user_id=21627 Are you interested in pursuing this feature? I cannot promise that I will apply it blankly, only that I will review it. ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-04-25 13:02 Message: Logged In: YES user_id=6324 If I create a patch that operates as described in my previous followup, will you apply it? Is there anything I can do to get this integrated into the main python trunk? I don't like having to repatch and rebuild python everytime a new version comes out that I need for some other reason :> ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-02-05 10:21 Message: Logged In: YES user_id=6324 1) Well, it lets python treat sys.stdin as a tty even if C stdin != python sys.stdin. It still checks to make sure sys.stdin is a tty using isatty(). If some user changes sys.stdin to point to a tty, but *wants* Python to treat it as a non-tty, then this might cause them some grief. I can't think of any case where they'd want to do that, though. The behavior would be unchanged when sys.stdin points to a regular file. 2) hmm.. I suppose, ideally, the readline module should smoothly handle sys.stdin being changed out from under it. Readline alters various terminal settings on rl_instream during initialization, though. For example, it changes the terminal to raw or cbreak mode from cooked mode, so that it can receive input a character at a time instead of a line at a time. It may be possible to uninitialized and reinitialized terminal each time call_readline is called, I suppose (I believe libreadline provides hooks for this). It would also have to check if sys.stdin is a tty, and call PyFile_GetLine if it is not. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-02-05 02:35 Message: Logged In: YES user_id=6656 Comments: 1) in what ways does this change existing behaviour? I can think of a few, but are there any that will inconvenience existing users 2) why not do the rl_instream = PySys_GetObject("stdin") dance in call_readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=512981&group_id=5470 From noreply@sourceforge.net Fri Oct 11 09:02:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 01:02:17 -0700 Subject: [Patches] [ python-Patches-512981 ] readline /dev/tty problem Message-ID: Patches item #512981, was opened at 2002-02-04 22:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=512981&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Stutzbach (agthorr) >Assigned to: Martin v. Löwis (loewis) Summary: readline /dev/tty problem Initial Comment: GNU readline doesn't work if the C symbol "stdin" is not a tty, even if the python symbol sys.stdin is. This will happen, for example, if a program initially receives input from a pipe, but then changes sys.stdin to read from /dev/tty. (This is how programs like "less" work) Here's a sample program that exhibits this behavior: ------------------------------------------------------------------------ #!/usr/bin/env python import sys mail = sys.stdin.read () sys.stdin = open ('/dev/tty', 'r') import readline foo = raw_input ('add_idea> ') print foo ------------------------------------------------------------------------ You can test this by saving the above program to a file (foo.py), piping data to it, then trying to use GNU readline editing commands at the prompt. E.g.: ------------------------------------------------------------------------ liberty:~$ cat ideas.html | ./foo.py add_idea> asdfsdf^Afoo asdfsdffoo ------------------------------------------------------------------------ The patch attached seems to fix the problem. You may want to grep the source for other modules that may have similar bugs. Also, this patch assumes that the readline module is imported *after* sys.stdin is changed. This much better than nothing (particularly if it's documented), but there may be a better solution. -- Agthorr ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-10-11 09:23 Message: Logged In: YES user_id=6324 Okay, I've attached a new patch that works as you suggested. Let me know if you have any questions or concerns. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-08 11:27 Message: Logged In: YES user_id=21627 I think you should implement a strategy to detect changes to sys.stdin dynamically. For example, the old sys.stdin could go away, closing the file, which would leave readline with a garbage pointer. Instead, I think you should hold onto sys.stdin, and compare this reference from time to time with the current sys.stdin, and arrange to reinitialize readline (if possible). ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-10-07 23:32 Message: Logged In: YES user_id=6324 Yes, I'm interested in pursuing it. Let me know what I can do to move this along. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 23:15 Message: Logged In: YES user_id=21627 Are you interested in pursuing this feature? I cannot promise that I will apply it blankly, only that I will review it. ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-04-25 22:02 Message: Logged In: YES user_id=6324 If I create a patch that operates as described in my previous followup, will you apply it? Is there anything I can do to get this integrated into the main python trunk? I don't like having to repatch and rebuild python everytime a new version comes out that I need for some other reason :> ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-02-05 19:21 Message: Logged In: YES user_id=6324 1) Well, it lets python treat sys.stdin as a tty even if C stdin != python sys.stdin. It still checks to make sure sys.stdin is a tty using isatty(). If some user changes sys.stdin to point to a tty, but *wants* Python to treat it as a non-tty, then this might cause them some grief. I can't think of any case where they'd want to do that, though. The behavior would be unchanged when sys.stdin points to a regular file. 2) hmm.. I suppose, ideally, the readline module should smoothly handle sys.stdin being changed out from under it. Readline alters various terminal settings on rl_instream during initialization, though. For example, it changes the terminal to raw or cbreak mode from cooked mode, so that it can receive input a character at a time instead of a line at a time. It may be possible to uninitialized and reinitialized terminal each time call_readline is called, I suppose (I believe libreadline provides hooks for this). It would also have to check if sys.stdin is a tty, and call PyFile_GetLine if it is not. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-02-05 11:35 Message: Logged In: YES user_id=6656 Comments: 1) in what ways does this change existing behaviour? I can think of a few, but are there any that will inconvenience existing users 2) why not do the rl_instream = PySys_GetObject("stdin") dance in call_readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=512981&group_id=5470 From noreply@sourceforge.net Fri Oct 11 11:52:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 03:52:48 -0700 Subject: [Patches] [ python-Patches-580869 ] Fix for seg fault on test_re on mac osx Message-ID: Patches item #580869, was opened at 2002-07-13 03:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven D. Majewski (sdm7g) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Fix for seg fault on test_re on mac osx Initial Comment: import resource soft, hard = resource.getrlimit( resource.RLIMIT_STACK ) resource.setrlimit( resource.RLIMIT_STACK, (1024 * 2048, hard)) is the python equivalent of the tcsh 'limit stack 2048' and will keep python from seg faulting on test_re . ( maybe wrapped in a "if os.platform == 'darwin' : " -- are there any other systems that have this problem ? ) -- Steve Majewski ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-10-11 10:52 Message: Logged In: YES user_id=6656 > (Aside: why does this build `python' for 10.1 but > `python.exe' for 10.2?) Because the sf machine has a case sensitive filesystem? I don't see any failures on 10.1.5 (after I ran ulimit, duh). Haven't tried this patch yet... ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-11 06:42 Message: Logged In: YES user_id=12800 Ok, I've added the Wouters Elaboration to regrtest.py and verified it works on both 10.1 and 10.2 (the former being the OSX machine on the SF compile farm and the latter being my home machine). Attached is the patch (I hope :). (Aside: why does this build `python' for 10.1 but `python.exe' for 10.2?) I think this patch is fine for Py2.2.2. Today Guido said he'd feel more comfortable with a patch to main.c than a patch to regrtest.py, s?re.py, or site.py (if I understood him correctly). However, I don't think there's time for that for Py2.2.2. Perhaps we should simply commit this simple fix so the test suite passes, and then work out a more comprehensive patch for Py2.3? Note that In addition, here is the output of the regrtest on 10.1 and 10.2. Is it worth spending time trying to fix these for the Py2.2.2 release? 10.1: 170 tests OK. 2 tests failed: test_fcntl test_largefile 21 tests skipped: test_al test_cd test_cl test_curses test_dl test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_minidom test_poll test_pyexpat test_sax test_socket_ssl test_socketserver test_sunaudiodev test_unicode_file test_winreg test_winsound 3 skips unexpected on darwin: test_sax test_pyexpat test_locale make: *** [test] Error 1 10.2: 171 tests OK. 1 test failed: test_locale 21 tests skipped: test_al test_cd test_cl test_curses test_dl test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_minidom test_nis test_poll test_pyexpat test_sax test_socket_ssl test_socketserver test_sunaudiodev test_unicode_file test_winreg test_winsound 2 skips unexpected on darwin: test_sax test_pyexpat ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2002-10-10 22:38 Message: Logged In: YES user_id=34209 Oh, and the diff is kind of amusing. It seems to be MacBinary, but 'file' on my Debian machine isn't quite sure: /home/thomas/regrtest.diff: MacBinary III data with surprising version number Fortunately it's still readable :-) I guess I should go back to "cool with a Macintosh" too. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2002-10-10 22:28 Message: Logged In: YES user_id=34209 I'd suggest adding a min(max, ) to the patch, so that it becomes: soft, hard = resource.getrlimit(resource.RLIMIT_STACK) newsoft = min(hard, max(soft, 1024*2048)) resource.setrlimit(resource.RLIMIT_STACK, newsoft, hard) And if the test suite only triggers this problem, doesn't it make more sense in s?re.py, as Fredrik suggested ? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-10 19:05 Message: Logged In: YES user_id=12800 I can verify the patch works on 10.1, specifically the OSX Server in the SF compile farm. ---------------------------------------------------------------------- Comment By: Steven D. Majewski (sdm7g) Date: 2002-10-10 17:11 Message: Logged In: YES user_id=105602 NOT running as root -- I just tried it again and verified that it works for me. HOWEVER: I haven't yet upgraded to Jaguar/10.2 Maybe that's the difference ? I can post a request on the pythonmac list and ask some others to try it and find out if it's a 10.1.x vs 10.2 thing. -- Steve ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 16:04 Message: Logged In: YES user_id=44345 Sorry for the bogus updates. Opera 6.0 Beta 1 apparently has file upload problems. Resorting to IE... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 16:01 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 16:01 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 16:00 Message: Logged In: YES user_id=44345 BTW, attached is my diff against regrtest.py. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-10 15:57 Message: Logged In: YES user_id=44345 I tried adding the above code to regrtest.py. When I tried to run python regrtest.py test_re I got a ValueError exception: "not allowed to raise maximum limit". I have no trouble using the ulimit builtin command to raise my stack size. Steve, were you perhaps running as root when you tried this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=5470 From noreply@sourceforge.net Fri Oct 11 15:04:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 07:04:59 -0700 Subject: [Patches] [ python-Patches-621891 ] tkFileDialog multiple option Message-ID: Patches item #621891, was opened at 2002-10-11 14:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621891&group_id=5470 Category: Tkinter Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Martin Franklin (mfranklin1) Assigned to: Nobody/Anonymous (nobody) Summary: tkFileDialog multiple option Initial Comment: In tk8.4 tk_getOpenFile and tk_getSaveFile dialogs used by tkFileDialog.py now allow the multiple option on all platforms, according to the docs... I have only tested in Linux (RedHat 7.2) python 2.2.1 and tk 8.4 This patch adds two new functions to the tkFileDialog module askopenfilenames() and askopenfiles() the function doc strings explain what they do... I've uploaded a diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621891&group_id=5470 From noreply@sourceforge.net Fri Oct 11 17:01:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 09:01:57 -0700 Subject: [Patches] [ python-Patches-621948 ] docstring for md5 Message-ID: Patches item #621948, was opened at 2002-10-11 12:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621948&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: David M. Cooke (dmcooke) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: docstring for md5 Initial Comment: The docstring for the md5 type doesn't mention the hexdigest method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621948&group_id=5470 From noreply@sourceforge.net Fri Oct 11 18:27:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 10:27:45 -0700 Subject: [Patches] [ python-Patches-599836 ] Bugfix for urllib2.py Message-ID: Patches item #599836, was opened at 2002-08-25 07:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599836&group_id=5470 Category: Library (Lib) Group: Python 2.2.x >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Jeremy Hylton (jhylton) Summary: Bugfix for urllib2.py Initial Comment: OpenerDirector has a default User-agent header. That wouldn't be a problem, except that AbstractHTTPHandler uses the headers in OpenerDirector.addheaders *after* a Request has been instantiated, thus making that default override whatever headers were given to Request. This patch checks to make sure a header isn't already in a Request before adding the OpenerDirector's headers. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 17:27 Message: Logged In: YES user_id=31392 Fixed in rev 1.36. Changed case, even though the headers aren't case sensitive. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-10 18:17 Message: Logged In: NO Is there any reasons to not use the same case as Mozilla, IE and the RFC in the User-Agent HTTP header? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-06 15:50 Message: Logged In: NO Unless you want problems, I suggest you to use the same case as Mozilla, IE and the RFC in the User-Agent HTTP header. --- python/dist/src/Lib/urllib.py +++ python/dist/src/Lib/urllib.py @@ -104,7 +104,7 @@ self.proxies = proxies self.key_file = x509.get('key_file') self.cert_file = x509.get('cert_file') - self.addheaders = [('User-agent', self.version)] + self.addheaders = [('User-Agent', self.version)] self.__tempfiles = [] self.__unlink = os.unlink # See cleanup() self.tempcache = None --- python/dist/src/Lib/urllib2.py +++ python/dist/src/Lib/urllib2.py @@ -247,7 +247,7 @@ class OpenerDirector: def __init__(self): server_version = "Python-urllib/%s" % __version__ - self.addheaders = [('User-agent', server_version)] + self.addheaders = [('User-Agent', server_version)] # manage the individual handlers self.handlers = [] self.handle_open = {} ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 18:56 Message: Logged In: YES user_id=6380 For Jeremy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599836&group_id=5470 From noreply@sourceforge.net Fri Oct 11 22:55:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 14:55:38 -0700 Subject: [Patches] [ python-Patches-621948 ] docstring for md5 Message-ID: Patches item #621948, was opened at 2002-10-11 12:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621948&group_id=5470 Category: Documentation >Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: David M. Cooke (dmcooke) >Assigned to: Neal Norwitz (nnorwitz) Summary: docstring for md5 Initial Comment: The docstring for the md5 type doesn't mention the hexdigest method. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-11 17:55 Message: Logged In: YES user_id=33168 Thanks! Checked in as md5module.c 2.34 and 2.27.6.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621948&group_id=5470 From noreply@sourceforge.net Fri Oct 11 23:06:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 15:06:26 -0700 Subject: [Patches] [ python-Patches-539360 ] Webbrowser.py and konqueror Message-ID: Patches item #539360, was opened at 2002-04-04 12:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=539360&group_id=5470 Category: Library (Lib) >Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Andy McKay (zopezen) >Assigned to: Neal Norwitz (nnorwitz) Summary: Webbrowser.py and konqueror Initial Comment: The open function for konqueror would always fail on the assert. The assert would check the action did not contain a single quote. The url passed through in the open function would always contain a single quote. The assert should check the incoming url for a single quote. If its properly quoted then you can pass on to _remote. Secondly since the _remote url is now correctly quoted, there is no need for a second set of quotes on the kfmclient. Tested on Kde 2.2. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-11 18:06 Message: Logged In: YES user_id=33168 Thanks! Checked in as webbrowser.py 1.34 and 1.26.6.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=539360&group_id=5470 From noreply@sourceforge.net Sat Oct 12 00:05:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 16:05:32 -0700 Subject: [Patches] [ python-Patches-613173 ] koi8_u codec Message-ID: Patches item #613173, was opened at 2002-09-23 08:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613173&group_id=5470 Category: Library (Lib) >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Maxim Dzumanenko (mdzumanenko) >Assigned to: M.-A. Lemburg (lemburg) Summary: koi8_u codec Initial Comment: This patch adds koi8_u codec ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-11 19:05 Message: Logged In: YES user_id=33168 I've updated the patch for whitespace normalization and made hex chars a-f instead of A-F. It is easy to do a diff between koi8_[ru].py now. I have no idea if the encoding is correct. If someone can verify it is correct, assign back to me for checkin. Also, should this be backported if accepted? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613173&group_id=5470 From noreply@sourceforge.net Sat Oct 12 13:08:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Oct 2002 05:08:47 -0700 Subject: [Patches] [ python-Patches-613173 ] koi8_u codec Message-ID: Patches item #613173, was opened at 2002-09-23 12:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613173&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Maxim Dzumanenko (mdzumanenko) Assigned to: M.-A. Lemburg (lemburg) Summary: koi8_u codec Initial Comment: This patch adds koi8_u codec ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-12 12:08 Message: Logged In: YES user_id=38388 Here's a new version of the codec which fixes some encoding bugs and uses the approach of inheriting KOI8R as suggested by the RFC. Also changed the copyright to the PSF. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-11 23:05 Message: Logged In: YES user_id=33168 I've updated the patch for whitespace normalization and made hex chars a-f instead of A-F. It is easy to do a diff between koi8_[ru].py now. I have no idea if the encoding is correct. If someone can verify it is correct, assign back to me for checkin. Also, should this be backported if accepted? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613173&group_id=5470 From noreply@sourceforge.net Sat Oct 12 13:10:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Oct 2002 05:10:10 -0700 Subject: [Patches] [ python-Patches-613173 ] koi8_u codec Message-ID: Patches item #613173, was opened at 2002-09-23 12:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613173&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Maxim Dzumanenko (mdzumanenko) Assigned to: M.-A. Lemburg (lemburg) Summary: koi8_u codec Initial Comment: This patch adds koi8_u codec ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-12 12:10 Message: Logged In: YES user_id=38388 About the backport: new codecs can generally always be backported. Please check the code into 2.3 and 2.2.2. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-12 12:08 Message: Logged In: YES user_id=38388 Here's a new version of the codec which fixes some encoding bugs and uses the approach of inheriting KOI8R as suggested by the RFC. Also changed the copyright to the PSF. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-11 23:05 Message: Logged In: YES user_id=33168 I've updated the patch for whitespace normalization and made hex chars a-f instead of A-F. It is easy to do a diff between koi8_[ru].py now. I have no idea if the encoding is correct. If someone can verify it is correct, assign back to me for checkin. Also, should this be backported if accepted? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613173&group_id=5470 From noreply@sourceforge.net Sat Oct 12 13:13:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Oct 2002 05:13:44 -0700 Subject: [Patches] [ python-Patches-613173 ] koi8_u codec Message-ID: Patches item #613173, was opened at 2002-09-23 12:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613173&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Maxim Dzumanenko (mdzumanenko) >Assigned to: Neal Norwitz (nnorwitz) Summary: koi8_u codec Initial Comment: This patch adds koi8_u codec ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-12 12:10 Message: Logged In: YES user_id=38388 About the backport: new codecs can generally always be backported. Please check the code into 2.3 and 2.2.2. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-12 12:08 Message: Logged In: YES user_id=38388 Here's a new version of the codec which fixes some encoding bugs and uses the approach of inheriting KOI8R as suggested by the RFC. Also changed the copyright to the PSF. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-11 23:05 Message: Logged In: YES user_id=33168 I've updated the patch for whitespace normalization and made hex chars a-f instead of A-F. It is easy to do a diff between koi8_[ru].py now. I have no idea if the encoding is correct. If someone can verify it is correct, assign back to me for checkin. Also, should this be backported if accepted? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613173&group_id=5470 From noreply@sourceforge.net Sun Oct 13 08:07:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 00:07:59 -0700 Subject: [Patches] [ python-Patches-622537 ] dummy_thread.py implementation Message-ID: Patches item #622537, was opened at 2002-10-13 00:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=622537&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: dummy_thread.py implementation Initial Comment: As mentioned in Zack Weinberg's Python-dev thread, "A few lessons from the tempfile.py rewrite", it was brought up that not having thread in all distributions is a pain because you have to write around instances of it not existing. Guido suggested the compromise of having a dummy_thread.py so that one could do: try: import thread as _thread except ImportError: import dummy_thread as _thread This is specific comment can be found at http://mail.python.org/pipermail/python-dev/2002-August/027985.html . Well, I decided to implement dummy_thread.py . I have tested it against test_thread.py and test_threading.py by editing the files locally to import dummy_thread as thread. All tests did pass. The only thing that is not necessarily straight-forward in the implementation is that for non-blocking lock.acquire() calls, the code actually checks to see if the lock is available; blocking calls just automatically acquire the lock since blocking when there is not real threading would not big good. =) It was also to appease the assert demons in threading.py for Condition objects since Condition._is_owned() did not like having lock.acquire() always succeed. As for adding regression tests, one could just run test_thread.py specifically against dummy_thread.py . The tougher test, though, was getting test_threading.py to work with threading.py importing dummy_thread. I am not, as of this exact moment, uploading any patches to add regression tests since I wrote this on a whim and I am leaving for vacation on 2002-10-14. I will be back by November 1, though, and I can try to come up with how to integrate regression tests then if no one has beaten me to it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=622537&group_id=5470 From noreply@sourceforge.net Sun Oct 13 11:22:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 03:22:53 -0700 Subject: [Patches] [ python-Patches-621205 ] Tkinter updates for tk8.4 Message-ID: Patches item #621205, was opened at 2002-10-10 11:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621205&group_id=5470 Category: Tkinter Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Martin Franklin (mfranklin1) Assigned to: Martin v. Löwis (loewis) Summary: Tkinter updates for tk8.4 Initial Comment: This patch includes three new widgets : PanedWindow, Spinbox and LabelFrame I have also added the edit_* methods to the Text widget It requires tk 8.4 but should not fall over on earlier versions (provided the end user does not use these options) I've uploaded a diff -c ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 12:22 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as Tkinter.py 1.165; ACKS 1.210; NEWS 1.499; ---------------------------------------------------------------------- Comment By: Martin Franklin (mfranklin1) Date: 2002-10-10 21:32 Message: Logged In: YES user_id=482545 Done. I've uploaded the latest diff file. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 19:09 Message: Logged In: YES user_id=21627 The text of the doc strings is all fine; as you know, they ought to be in inidicative form (or is it imperative?). However, please separate the first sentence from the following ones by an empty line. This allows interactive tools to print a tooltip. ---------------------------------------------------------------------- Comment By: Martin Franklin (mfranklin1) Date: 2002-10-10 17:02 Message: Logged In: YES user_id=482545 The second patch (2002-10-10 09:18) is (was) the correct version I will upload a new one with your comments in mind. The test for Tcl version was commented out to get a response (and it did!) so I will remove it. The pathName comments should have been removed and will be soon (as will the blank lines) I have also gone on and added a few comments to the Button and Label widget (these now support the -compound option) and I have updated the module comment at the top of the module to include the new Widgets so pydoc can pick them up. The Wm class has sprung a new method I can't find any more updates on the tcl tk site... but there may be some small ones.... I would be interested in your comments on the style of the doc strings for the new widgets. Basically I have cut and pasted from the tk command reference pages (with a few light edits) This means they are different from the older widgets ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 16:46 Message: Logged In: YES user_id=21627 Which version of the patch is the correct one? There is no need to test the Tcl version when wrapping new Tcl features: as long as Tkinter continues to import correctly on older Tk versions, it is fine that invoking the newer wrappers will cause Tcl errors. What are the pathName comment lines? Please don't add that many blank lines. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621205&group_id=5470 From noreply@sourceforge.net Sun Oct 13 11:44:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 03:44:35 -0700 Subject: [Patches] [ python-Patches-512981 ] readline /dev/tty problem Message-ID: Patches item #512981, was opened at 2002-02-04 22:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=512981&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Stutzbach (agthorr) Assigned to: Martin v. Löwis (loewis) Summary: readline /dev/tty problem Initial Comment: GNU readline doesn't work if the C symbol "stdin" is not a tty, even if the python symbol sys.stdin is. This will happen, for example, if a program initially receives input from a pipe, but then changes sys.stdin to read from /dev/tty. (This is how programs like "less" work) Here's a sample program that exhibits this behavior: ------------------------------------------------------------------------ #!/usr/bin/env python import sys mail = sys.stdin.read () sys.stdin = open ('/dev/tty', 'r') import readline foo = raw_input ('add_idea> ') print foo ------------------------------------------------------------------------ You can test this by saving the above program to a file (foo.py), piping data to it, then trying to use GNU readline editing commands at the prompt. E.g.: ------------------------------------------------------------------------ liberty:~$ cat ideas.html | ./foo.py add_idea> asdfsdf^Afoo asdfsdffoo ------------------------------------------------------------------------ The patch attached seems to fix the problem. You may want to grep the source for other modules that may have similar bugs. Also, this patch assumes that the readline module is imported *after* sys.stdin is changed. This much better than nothing (particularly if it's documented), but there may be a better solution. -- Agthorr ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 12:44 Message: Logged In: YES user_id=21627 It appears that your patch can crash when sys.stdin/out is not a file anymore: >>> import readline >>> import codecs,sys >>> sys.stdout=codecs.getwriter('utf-8')(sys.stdout) Segmentation fault (core dumped) ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-10-11 09:23 Message: Logged In: YES user_id=6324 Okay, I've attached a new patch that works as you suggested. Let me know if you have any questions or concerns. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-08 11:27 Message: Logged In: YES user_id=21627 I think you should implement a strategy to detect changes to sys.stdin dynamically. For example, the old sys.stdin could go away, closing the file, which would leave readline with a garbage pointer. Instead, I think you should hold onto sys.stdin, and compare this reference from time to time with the current sys.stdin, and arrange to reinitialize readline (if possible). ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-10-07 23:32 Message: Logged In: YES user_id=6324 Yes, I'm interested in pursuing it. Let me know what I can do to move this along. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 23:15 Message: Logged In: YES user_id=21627 Are you interested in pursuing this feature? I cannot promise that I will apply it blankly, only that I will review it. ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-04-25 22:02 Message: Logged In: YES user_id=6324 If I create a patch that operates as described in my previous followup, will you apply it? Is there anything I can do to get this integrated into the main python trunk? I don't like having to repatch and rebuild python everytime a new version comes out that I need for some other reason :> ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-02-05 19:21 Message: Logged In: YES user_id=6324 1) Well, it lets python treat sys.stdin as a tty even if C stdin != python sys.stdin. It still checks to make sure sys.stdin is a tty using isatty(). If some user changes sys.stdin to point to a tty, but *wants* Python to treat it as a non-tty, then this might cause them some grief. I can't think of any case where they'd want to do that, though. The behavior would be unchanged when sys.stdin points to a regular file. 2) hmm.. I suppose, ideally, the readline module should smoothly handle sys.stdin being changed out from under it. Readline alters various terminal settings on rl_instream during initialization, though. For example, it changes the terminal to raw or cbreak mode from cooked mode, so that it can receive input a character at a time instead of a line at a time. It may be possible to uninitialized and reinitialized terminal each time call_readline is called, I suppose (I believe libreadline provides hooks for this). It would also have to check if sys.stdin is a tty, and call PyFile_GetLine if it is not. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-02-05 11:35 Message: Logged In: YES user_id=6656 Comments: 1) in what ways does this change existing behaviour? I can think of a few, but are there any that will inconvenience existing users 2) why not do the rl_instream = PySys_GetObject("stdin") dance in call_readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=512981&group_id=5470 From noreply@sourceforge.net Sun Oct 13 11:49:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 03:49:18 -0700 Subject: [Patches] [ python-Patches-619108 ] Fix test_pep277 on Win9x Message-ID: Patches item #619108, was opened at 2002-10-06 03:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619108&group_id=5470 Category: Windows Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: Fix test_pep277 on Win9x Initial Comment: In the interests of getting test_pep277 running for Tim , sys.getwindowsversion() should be added. Chose sys as that is where all other version related information is found. Happy to move to the os module is desired, but posixmodule.c is enough of a mess already. Patch even includes doc :) Martin, could you please review? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-08 04:47 Message: Logged In: YES user_id=14198 OK, all checked in, including a new enhanced sys.getwindowsversion() that returns a tuple. Just don't complain about the magic numbers /cvsroot/python/python/dist/src/Python/sysmodule.c,v <-- sysmodule.c new revision: 2.111; previous revision: 2.110 /cvsroot/python/python/dist/src/Doc/lib/libsys.tex,v <-- libsys.tex new revision: 1.61; previous revision: 1.60 /cvsroot/python/python/dist/src/Doc/lib/libposixpath.tex,v <-- libposixpath.tex new revision: 1.29; previous revision: 1.28 /cvsroot/python/python/dist/src/Lib/dospath.py,v <-- dospath.py new revision: 1.30; previous revision: 1.29 /cvsroot/python/python/dist/src/Lib/macpath.py,v <-- macpath.py new revision: 1.40; previous revision: 1.39 /cvsroot/python/python/dist/src/Lib/ntpath.py,v <-- ntpath.py new revision: 1.50; previous revision: 1.49 /cvsroot/python/python/dist/src/Lib/os2emxpath.py,v <-- os2emxpath.py new revision: 1.7; previous revision: 1.6 /cvsroot/python/python/dist/src/Lib/posixpath.py,v <-- posixpath.py new revision: 1.53; previous revision: 1.52 /cvsroot/python/python/dist/src/Lib/test/test_pep277.py,v <-- test_pep277.py new revision: 1.4; previous revision: 1.3 /cvsroot/python/python/dist/src/Lib/test/output/test_pep277,v <-- test_pep277 new revision: 1.2; previous revision: 1.1 /cvsroot/python/python/dist/src/Misc/NEWS,v <-- NEWS new revision: 1.495; previous revision: 1.494 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 16:17 Message: Logged In: YES user_id=21627 Right; that's os.path.supports_unicode_filenames. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-06 15:30 Message: Logged In: YES user_id=6380 But sys.path.supports_unicode_filenames was a typo, right? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 14:18 Message: Logged In: YES user_id=21627 Mark wants it to be in sys; I have no preference in either direction. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-06 13:53 Message: Logged In: YES user_id=6380 Did you mean sys, or os? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 13:41 Message: Logged In: YES user_id=21627 Attached is a patch that uses getwindowsversion as I just suggested. Back to Mark for comments and possible checkin. The libsys.tex change also needs a \versionadded. If sys.getwindowsversion remains signed, this patch must be adjusted. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 09:25 Message: Logged In: YES user_id=21627 I'm in favour of adding sys.getwindowsversion. As for disabling the test, it seems like Tim prefers to add sys.path.supports_unicode_filenames, with the following settings: posixpath, macpath, dospath, os2emxpath: False ntpath: getwindowsversion() < 0x80000000 I'm somewhat confused about the signedness of GetVersion(), though - it appears that it is unsigned in C. If so, I think the Python wrapper should also return non-negative numbers only. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=619108&group_id=5470 From noreply@sourceforge.net Sun Oct 13 13:48:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 05:48:42 -0700 Subject: [Patches] [ python-Patches-569328 ] names in types module Message-ID: Patches item #569328, was opened at 2002-06-15 11:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=569328&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Oren Tirosh (orenti) Assigned to: Nobody/Anonymous (nobody) Summary: names in types module Initial Comment: Adds names to types module so types are accessible as 'type.spam' in addition to the existing longer version 'types.SpamType'. The short names match the type's __name__ attribute. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 14:48 Message: Logged In: YES user_id=21627 Oren, I sympathise with Fredrik's view. Unless there is somebody speaking in favour of these changes, I'll reject this patch by November 1. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2002-07-01 20:15 Message: Logged In: YES user_id=38376 "from * import types" is a rather common pydiom, and I'm pretty sure most people using that expects to get a bunch of [A-Z]\w+Type names, and nothing else. -0 from me. ---------------------------------------------------------------------- Comment By: Oren Tirosh (orenti) Date: 2002-06-18 16:40 Message: Logged In: YES user_id=562624 Updated patch. ---------------------------------------------------------------------- Comment By: Oren Tirosh (orenti) Date: 2002-06-15 12:58 Message: Logged In: YES user_id=562624 http://mail.python.org/pipermail/python-dev/2002-June/025410.html ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-15 12:05 Message: Logged In: YES user_id=21627 What is the purpose of this change? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=569328&group_id=5470 From noreply@sourceforge.net Sun Oct 13 13:53:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 05:53:18 -0700 Subject: [Patches] [ python-Patches-613256 ] add unescape method to xml.sax.saxutils Message-ID: Patches item #613256, was opened at 2002-09-23 17:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613256&group_id=5470 Category: XML Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Boedicker (mboedick) >Assigned to: Martin v. Löwis (loewis) Summary: add unescape method to xml.sax.saxutils Initial Comment: This patch adds an unescape() method to saxutils to convert an xml-escaped string back to its original form It also modifies the escape() method so that the core escaping takes places after any additional escaping passed in via the dictionary. This will guarantee that returned string is properly escaped for xml no matter what is passed in via the dictionary. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 14:53 Message: Logged In: YES user_id=21627 Can you please provide documentation and test cases? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613256&group_id=5470 From noreply@sourceforge.net Sun Oct 13 13:55:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 05:55:51 -0700 Subject: [Patches] [ python-Patches-578688 ] incompatible, but nice strings improveme Message-ID: Patches item #578688, was opened at 2002-07-08 16:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=578688&group_id=5470 Category: Parser/Compiler Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Stepan Koltsov (yozh) Assigned to: Nobody/Anonymous (nobody) Summary: incompatible, but nice strings improveme Initial Comment: This patch changes interpretation of multiline strings (desn't matter, single, double quoted (when NL escaped with backslash), triple quoted). After applying this patch, first: first charachter after opening quote is ignored, if it is NL, example: """ la-la-la """ will be equivalent of """la-la-la """ First variant looks better, isn't is? Second: all spaces after NL before first nonblack char but no more then current indentation are ignored, example: New: def f(): """ This is docstring, mama-mama, apple, banana """ is equivalent of old: def f(): """This is docstring, mama-mama, apple, banana """ Patch enabled if PyPARSE_STRIPPED_STRINGS defined. I suggest you to apply patch but undefine PyPARSE_STRIPPED_STRINGS until python-4 ;-) I am sure, that this semantics is right, as alternative, I suggest adding new modifier 'i' to strings, like 'u' and 'r', for inst. i'iddqd'. P. S. AFAIU, editing of parsermodule.c needed. P. P. S. I am sorry, my English suck :-( ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 14:55 Message: Logged In: YES user_id=21627 Given that PEP 295 was rejected, I also reject this patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 06:09 Message: Logged In: YES user_id=80475 This proposal does not have much of a chance. It offers only a minor gain (debatable) but assures incompatability. I recommend that the OP take Martin's hint and withdraw or close the patch. If you need it badly, a PEP is essential. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-09 10:13 Message: Logged In: YES user_id=21627 In that case,I think your proposed change will be highly debated. That means you will have to write a PEP first if you want to see it implemented (even if it is only an option). ---------------------------------------------------------------------- Comment By: Stepan Koltsov (yozh) Date: 2002-07-08 18:06 Message: Logged In: YES user_id=247706 I think the first part is still needed since 1. In r"""\ lalala """ backslash doesn't escape NL 2. I think it looks better. About second part: 1. Additional library routines make program text less readable. 2. They cannot know what indentation in spaces was where string constant appeared. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-08 17:48 Message: Logged In: YES user_id=21627 The first part of your patch is not needed, you can just as fine write """\ la-la-la """ to escape the first newline. The second patch is probably not needed either, since you can easily write library routines that deal with that kind of stripping. In fact, pydoc already does that transformation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=578688&group_id=5470 From noreply@sourceforge.net Sun Oct 13 14:01:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 06:01:14 -0700 Subject: [Patches] [ python-Patches-572628 ] opt. timeouts for Queue.put() and .get() Message-ID: Patches item #572628, was opened at 2002-06-23 02:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572628&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Chris Liechti (cliechti) Assigned to: Nobody/Anonymous (nobody) Summary: opt. timeouts for Queue.put() and .get() Initial Comment: Sometimes one wants a Queue that doesn't block forever on a get() or put(). Both should be able to return after a certain time, acting like they were called non-blocking and failed. i.e get() raises the Empty exception when it times out, put() raises Full. This patch adds optional timeout arguments to these methods. The old 'block' arg is left and behaves 100% like in the old days (backwards compatibility). The new feature appears only when 'block' is true and 'timeout' is a positive number. The new code is basicaly a merge between the original Queue.py's put() and get() and threading.py's _Event.wait() --- code that's proven to work, nothing realy new here. I also added some simple tests to the test_queue.py script for the new feature. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 15:01 Message: Logged In: YES user_id=21627 Can you please provide documentation changes (for libqueue.tex) as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572628&group_id=5470 From noreply@sourceforge.net Sun Oct 13 14:02:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 06:02:17 -0700 Subject: [Patches] [ python-Patches-583180 ] smtplib.py patch for macmail esmtp auth Message-ID: Patches item #583180, was opened at 2002-07-18 04:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=583180&group_id=5470 Category: Library (Lib) Group: Python 2.2.x >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: bob kuehne (mysticbob) Assigned to: Nobody/Anonymous (nobody) Summary: smtplib.py patch for macmail esmtp auth Initial Comment: i ran into a problem that i've seen several other people describe where they can't authenticate to their particular mail server. i dug into this (my mail server is smtp.mac.com) and discovered that smtplib.py didn't support the specific type of auth that this server required. so, this patch,allows authentication to these specific server types. i also reworked one token to make it a bit more modular. the patch is attached, generated of form: diff smtplib.py_orig smtplib.py_new i'm new to python, and new to the whole patch process on sourceforge, so please let me know what i can do to test, or how else i can work to get this in the next python version. thank you! bob ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 15:02 Message: Logged In: YES user_id=21627 The auth=login patch has been applied, so this one should be obsolete. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-24 00:03 Message: Logged In: YES user_id=21627 On patches: Please always use context (-c) or unified (-u) diffs; those stay valid longer. On AUTH=LOGIN: Can you please try http://sourceforge.net/tracker/index.php? func=detail&aid=572031&group_id=5470&atid=305470 This pre-RFC AUTH protocol is by far not an invention of smtp.mac.com (or specific to it) - it is originally a Netscape invention, and widely implemented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=583180&group_id=5470 From noreply@sourceforge.net Sun Oct 13 14:03:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 06:03:45 -0700 Subject: [Patches] [ python-Patches-574707 ] makesockaddr, use addrlen with AF_UNIX Message-ID: Patches item #574707, was opened at 2002-06-27 20:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=574707&group_id=5470 Category: Modules Group: Python 2.1.2 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Donn Cave (donnc) Assigned to: Nobody/Anonymous (nobody) Summary: makesockaddr, use addrlen with AF_UNIX Initial Comment: makesockaddr(), in 2.1 source, expects a NUL terminated string in sockaddr_un.sun_path. That expectation is routinely not met on some platforms - NetBSD 1.5.2, AIX 4.3.3, probably others. This patch shows how to use addrlen to determine the correct length of the value of sun_path. Here's the diff (I have no idea what it means to "attach" a file from my web browser), against 2.1 source. *** socketmodule.c.dist Sun Apr 15 17:21:33 2001 --- socketmodule.c Thu Jun 27 11:09:57 2002 *************** *** 597,603 **** case AF_UNIX: { struct sockaddr_un *a = (struct sockaddr_un *) addr; ! return PyString_FromString(a->sun_path); } #endif --- 597,605 ---- case AF_UNIX: { struct sockaddr_un *a = (struct sockaddr_un *) addr; ! return PyString_FromStringAndSize(a->sun_path, ! addrlen - ! (sizeof(struct sockaddr_un) - sizeof(a ->sun_path))); } #endif ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 15:03 Message: Logged In: YES user_id=21627 I'm closing this because of lack of responsiveness. If you ever find a chance to look at this stuff again, please submit a new patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-28 18:25 Message: Logged In: YES user_id=21627 This patch does not work. On systems where a NUL is returned, this NUL is also accounted-for in addrlen, and hence included in the string. Would you like to revise your patch to support both cases? Feel free to use the offsetof macro, btw. Attaching a file is done by checking "Check to Upload and Attach a File:" and adding a file name in the field below. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=574707&group_id=5470 From noreply@sourceforge.net Sun Oct 13 14:08:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 06:08:11 -0700 Subject: [Patches] [ python-Patches-605370 ] nntplib: group descriptions and RFC2980 Message-ID: Patches item #605370, was opened at 2002-09-06 04:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=605370&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jürgen A. Erhard (jae) Assigned to: Nobody/Anonymous (nobody) Summary: nntplib: group descriptions and RFC2980 Initial Comment: nntplib's NNTP.xgtitle() is deprecated by RFC2980. And some servers (like leafnode) don't even know XGTITLE. This adds two methods to NNTP, description and descriptions. NNTP.description just gets the description of one group (and doesn't return the server status code). NNTP.descriptions does the same as xgtitle does now, but in a more general, and RFC2980 compliant way. It tries the RFC2980 way (LIST NEWSGROUPS) and if this fails, falls back to XGTITLE. This patch also adds an new optional "groups" argument to the NNTP.list. I thought it fitting to mirror the "LIST/LIST NEWSGROUPS" in the method. Feel free to kill this part, I'm not really attached to it. I do prefer description/descriptions, as they make the code more self-documenting. (If you insist: I'm on Debian GNU/Linux "sid", python2.2.1... but the patch should apply cleanly against CVS, doerwalter's checkin shouldn't conflict) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 15:08 Message: Logged In: YES user_id=21627 Can you please provide documentation patches (for libnntplib.tex) as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=605370&group_id=5470 From noreply@sourceforge.net Sun Oct 13 14:06:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 06:06:26 -0700 Subject: [Patches] [ python-Patches-590377 ] db4 include not found Message-ID: Patches item #590377, was opened at 2002-08-02 23:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: db4 include not found Initial Comment: setup.py looks for the db4 library in /usr/lib, but doesn't look for the header in /usr/include (as you find it on Debian unstable) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 15:06 Message: Logged In: YES user_id=21627 The patch is out-of-date, and appears to be unnecessary. I'm rejecting it - if you still think something needs to be done, please submit a new patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470 From noreply@sourceforge.net Sun Oct 13 14:55:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 06:55:27 -0700 Subject: [Patches] [ python-Patches-611760 ] zipfile.py reads archives with comments Message-ID: Patches item #611760, was opened at 2002-09-19 21:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=611760&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: James C. Ahlstrom (ahlstromjc) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile.py reads archives with comments Initial Comment: Module zipfile can not read ZIP archives which have appended archive comments. I have only gotten two complaints about this, but I feel that this limitation should be removed. Archive comments are appended to ZIP archives, and can be up to 64K bytes long. Reading them would require searching the end of the archive for the end record magic number. The attached patch will (1) seek and verify a zero length comment; and if this fails (2) search the last 4K bytes of the file for a comment. The 4K limitation (down from 64K) is for efficiency. This was tested on Python 2.2.1, but zipfile.py has changed since then. So the patch was hand edited into today's CVS zipfile.py version. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 15:55 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as zipfile.py 1.26; ---------------------------------------------------------------------- Comment By: James C. Ahlstrom (ahlstromjc) Date: 2002-09-20 16:07 Message: Logged In: YES user_id=64929 OK, here is a ZIP file which has an archive (appended) multiline comment. The comment is available as the attribute ZipFile::comment. I didn't add code to write ZIP files with comments. We don't need that, right? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-20 14:57 Message: Logged In: YES user_id=21627 Can you please attach an example zipfile to test this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=611760&group_id=5470 From noreply@sourceforge.net Sun Oct 13 15:13:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 07:13:16 -0700 Subject: [Patches] [ python-Patches-549901 ] use readline in pydoc.help if available Message-ID: Patches item #549901, was opened at 2002-04-28 23:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=549901&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Yallop (yallop) Assigned to: Nobody/Anonymous (nobody) Summary: use readline in pydoc.help if available Initial Comment: Interactive help (via pydoc.interact in 2.1 onwards) doesn't use GNU readline. This is easily amended by using raw_input() instead of input.readline(). The patch assumes that Helper.input is sys.stdin when Helper.interact() is called but can be fixed trivially if this assumption is invalid.. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 16:13 Message: Logged In: YES user_id=21627 Jeremy, are you willing to revise your patch, considering Guido's comment? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-07 14:30 Message: Logged In: YES user_id=6380 I like the idea, but not the execution. It should only use raw_input when self.input is sys.stdin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=549901&group_id=5470 From noreply@sourceforge.net Sun Oct 13 15:32:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 07:32:41 -0700 Subject: [Patches] [ python-Patches-599836 ] Bugfix for urllib2.py Message-ID: Patches item #599836, was opened at 2002-08-25 00:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599836&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Closed Resolution: Fixed Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Jeremy Hylton (jhylton) Summary: Bugfix for urllib2.py Initial Comment: OpenerDirector has a default User-agent header. That wouldn't be a problem, except that AbstractHTTPHandler uses the headers in OpenerDirector.addheaders *after* a Request has been instantiated, thus making that default override whatever headers were given to Request. This patch checks to make sure a header isn't already in a Request before adding the OpenerDirector's headers. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-10-13 07:32 Message: Logged In: NO Please also patch "urllib2.py" not only "urllib.py" --- python/dist/src/Lib/urllib.py +++ python/dist/src/Lib/urllib.py @@ -104,7 +104,7 @@ self.proxies = proxies self.key_file = x509.get('key_file') self.cert_file = x509.get('cert_file') - self.addheaders = [('User-agent', self.version)] + self.addheaders = [('User-Agent', self.version)] self.__tempfiles = [] self.__unlink = os.unlink # See cleanup() self.tempcache = None ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 10:27 Message: Logged In: YES user_id=31392 Fixed in rev 1.36. Changed case, even though the headers aren't case sensitive. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-10 11:17 Message: Logged In: NO Is there any reasons to not use the same case as Mozilla, IE and the RFC in the User-Agent HTTP header? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-06 08:50 Message: Logged In: NO Unless you want problems, I suggest you to use the same case as Mozilla, IE and the RFC in the User-Agent HTTP header. --- python/dist/src/Lib/urllib.py +++ python/dist/src/Lib/urllib.py @@ -104,7 +104,7 @@ self.proxies = proxies self.key_file = x509.get('key_file') self.cert_file = x509.get('cert_file') - self.addheaders = [('User-agent', self.version)] + self.addheaders = [('User-Agent', self.version)] self.__tempfiles = [] self.__unlink = os.unlink # See cleanup() self.tempcache = None --- python/dist/src/Lib/urllib2.py +++ python/dist/src/Lib/urllib2.py @@ -247,7 +247,7 @@ class OpenerDirector: def __init__(self): server_version = "Python-urllib/%s" % __version__ - self.addheaders = [('User-agent', server_version)] + self.addheaders = [('User-Agent', server_version)] # manage the individual handlers self.handlers = [] self.handle_open = {} ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 11:56 Message: Logged In: YES user_id=6380 For Jeremy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599836&group_id=5470 From noreply@sourceforge.net Sun Oct 13 18:24:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 10:24:48 -0700 Subject: [Patches] [ python-Patches-512981 ] readline /dev/tty problem Message-ID: Patches item #512981, was opened at 2002-02-04 13:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=512981&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Stutzbach (agthorr) Assigned to: Martin v. Löwis (loewis) Summary: readline /dev/tty problem Initial Comment: GNU readline doesn't work if the C symbol "stdin" is not a tty, even if the python symbol sys.stdin is. This will happen, for example, if a program initially receives input from a pipe, but then changes sys.stdin to read from /dev/tty. (This is how programs like "less" work) Here's a sample program that exhibits this behavior: ------------------------------------------------------------------------ #!/usr/bin/env python import sys mail = sys.stdin.read () sys.stdin = open ('/dev/tty', 'r') import readline foo = raw_input ('add_idea> ') print foo ------------------------------------------------------------------------ You can test this by saving the above program to a file (foo.py), piping data to it, then trying to use GNU readline editing commands at the prompt. E.g.: ------------------------------------------------------------------------ liberty:~$ cat ideas.html | ./foo.py add_idea> asdfsdf^Afoo asdfsdffoo ------------------------------------------------------------------------ The patch attached seems to fix the problem. You may want to grep the source for other modules that may have similar bugs. Also, this patch assumes that the readline module is imported *after* sys.stdin is changed. This much better than nothing (particularly if it's documented), but there may be a better solution. -- Agthorr ---------------------------------------------------------------------- >Comment By: Daniel Stutzbach (agthorr) Date: 2002-10-13 10:24 Message: Logged In: YES user_id=6324 Jeez. My apologies. I will submit a new patch within a few days, and this time I will do regression testing instead of just looking at the problem I was trying to fix. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 03:44 Message: Logged In: YES user_id=21627 It appears that your patch can crash when sys.stdin/out is not a file anymore: >>> import readline >>> import codecs,sys >>> sys.stdout=codecs.getwriter('utf-8')(sys.stdout) Segmentation fault (core dumped) ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-10-11 00:23 Message: Logged In: YES user_id=6324 Okay, I've attached a new patch that works as you suggested. Let me know if you have any questions or concerns. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-08 02:27 Message: Logged In: YES user_id=21627 I think you should implement a strategy to detect changes to sys.stdin dynamically. For example, the old sys.stdin could go away, closing the file, which would leave readline with a garbage pointer. Instead, I think you should hold onto sys.stdin, and compare this reference from time to time with the current sys.stdin, and arrange to reinitialize readline (if possible). ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-10-07 14:32 Message: Logged In: YES user_id=6324 Yes, I'm interested in pursuing it. Let me know what I can do to move this along. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 14:15 Message: Logged In: YES user_id=21627 Are you interested in pursuing this feature? I cannot promise that I will apply it blankly, only that I will review it. ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-04-25 13:02 Message: Logged In: YES user_id=6324 If I create a patch that operates as described in my previous followup, will you apply it? Is there anything I can do to get this integrated into the main python trunk? I don't like having to repatch and rebuild python everytime a new version comes out that I need for some other reason :> ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-02-05 10:21 Message: Logged In: YES user_id=6324 1) Well, it lets python treat sys.stdin as a tty even if C stdin != python sys.stdin. It still checks to make sure sys.stdin is a tty using isatty(). If some user changes sys.stdin to point to a tty, but *wants* Python to treat it as a non-tty, then this might cause them some grief. I can't think of any case where they'd want to do that, though. The behavior would be unchanged when sys.stdin points to a regular file. 2) hmm.. I suppose, ideally, the readline module should smoothly handle sys.stdin being changed out from under it. Readline alters various terminal settings on rl_instream during initialization, though. For example, it changes the terminal to raw or cbreak mode from cooked mode, so that it can receive input a character at a time instead of a line at a time. It may be possible to uninitialized and reinitialized terminal each time call_readline is called, I suppose (I believe libreadline provides hooks for this). It would also have to check if sys.stdin is a tty, and call PyFile_GetLine if it is not. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-02-05 02:35 Message: Logged In: YES user_id=6656 Comments: 1) in what ways does this change existing behaviour? I can think of a few, but are there any that will inconvenience existing users 2) why not do the rl_instream = PySys_GetObject("stdin") dance in call_readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=512981&group_id=5470 From noreply@sourceforge.net Sun Oct 13 20:17:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 12:17:39 -0700 Subject: [Patches] [ python-Patches-572628 ] opt. timeouts for Queue.put() and .get() Message-ID: Patches item #572628, was opened at 2002-06-23 02:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572628&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Chris Liechti (cliechti) Assigned to: Nobody/Anonymous (nobody) Summary: opt. timeouts for Queue.put() and .get() Initial Comment: Sometimes one wants a Queue that doesn't block forever on a get() or put(). Both should be able to return after a certain time, acting like they were called non-blocking and failed. i.e get() raises the Empty exception when it times out, put() raises Full. This patch adds optional timeout arguments to these methods. The old 'block' arg is left and behaves 100% like in the old days (backwards compatibility). The new feature appears only when 'block' is true and 'timeout' is a positive number. The new code is basicaly a merge between the original Queue.py's put() and get() and threading.py's _Event.wait() --- code that's proven to work, nothing realy new here. I also added some simple tests to the test_queue.py script for the new feature. ---------------------------------------------------------------------- >Comment By: Chris Liechti (cliechti) Date: 2002-10-13 21:17 Message: Logged In: YES user_id=403744 Here's the patch for the docs. I also updated the references to 0/1 to False/True in the other method descriptions. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 15:01 Message: Logged In: YES user_id=21627 Can you please provide documentation changes (for libqueue.tex) as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572628&group_id=5470 From noreply@sourceforge.net Sun Oct 13 20:52:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 12:52:33 -0700 Subject: [Patches] [ python-Patches-622704 ] core setup.py - platform error msg Message-ID: Patches item #622704, was opened at 2002-10-13 15:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=622704&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Rushby (woodsplitter) Assigned to: Nobody/Anonymous (nobody) Summary: core setup.py - platform error msg Initial Comment: I initially submitted this as a bug report; it has been discussed here: http://sourceforge.net/tracker/index.php? func=detail&aid=620364&group_id=5470&atid=105470 As Guido requested, I'm submitting "an actual patch in context diff format". This patch is against the latest CVS version (MAIN branch, rev 1.111) of setup.py. I tar-gz'ed the patch to prevent Windows from corrupting the newlines. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=622704&group_id=5470 From noreply@sourceforge.net Mon Oct 14 06:12:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 22:12:45 -0700 Subject: [Patches] [ python-Patches-512981 ] readline /dev/tty problem Message-ID: Patches item #512981, was opened at 2002-02-04 13:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=512981&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Stutzbach (agthorr) Assigned to: Martin v. Löwis (loewis) Summary: readline /dev/tty problem Initial Comment: GNU readline doesn't work if the C symbol "stdin" is not a tty, even if the python symbol sys.stdin is. This will happen, for example, if a program initially receives input from a pipe, but then changes sys.stdin to read from /dev/tty. (This is how programs like "less" work) Here's a sample program that exhibits this behavior: ------------------------------------------------------------------------ #!/usr/bin/env python import sys mail = sys.stdin.read () sys.stdin = open ('/dev/tty', 'r') import readline foo = raw_input ('add_idea> ') print foo ------------------------------------------------------------------------ You can test this by saving the above program to a file (foo.py), piping data to it, then trying to use GNU readline editing commands at the prompt. E.g.: ------------------------------------------------------------------------ liberty:~$ cat ideas.html | ./foo.py add_idea> asdfsdf^Afoo asdfsdffoo ------------------------------------------------------------------------ The patch attached seems to fix the problem. You may want to grep the source for other modules that may have similar bugs. Also, this patch assumes that the readline module is imported *after* sys.stdin is changed. This much better than nothing (particularly if it's documented), but there may be a better solution. -- Agthorr ---------------------------------------------------------------------- >Comment By: Daniel Stutzbach (agthorr) Date: 2002-10-13 22:12 Message: Logged In: YES user_id=6324 When in interactive mode, if the user changes sys.std[in|out], would you agree that the interpreter should continue using C std[in|out] to get commands? (this is the current behavior without my patch) The documentation for sys.std[in|out|err] seem to suggest one should be able to redirect them, but I'm not sure that's actually desirable. (Your example only crashes if the interpreter is in interactive mode.) I've included another patch assuming this is the desired behavior. I tried several permutations of interactive vs non-interactive, setting sys.stdin and/or sys.stdout to None, and doing this before and after initializing readline. ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-10-13 10:24 Message: Logged In: YES user_id=6324 Jeez. My apologies. I will submit a new patch within a few days, and this time I will do regression testing instead of just looking at the problem I was trying to fix. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 03:44 Message: Logged In: YES user_id=21627 It appears that your patch can crash when sys.stdin/out is not a file anymore: >>> import readline >>> import codecs,sys >>> sys.stdout=codecs.getwriter('utf-8')(sys.stdout) Segmentation fault (core dumped) ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-10-11 00:23 Message: Logged In: YES user_id=6324 Okay, I've attached a new patch that works as you suggested. Let me know if you have any questions or concerns. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-08 02:27 Message: Logged In: YES user_id=21627 I think you should implement a strategy to detect changes to sys.stdin dynamically. For example, the old sys.stdin could go away, closing the file, which would leave readline with a garbage pointer. Instead, I think you should hold onto sys.stdin, and compare this reference from time to time with the current sys.stdin, and arrange to reinitialize readline (if possible). ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-10-07 14:32 Message: Logged In: YES user_id=6324 Yes, I'm interested in pursuing it. Let me know what I can do to move this along. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 14:15 Message: Logged In: YES user_id=21627 Are you interested in pursuing this feature? I cannot promise that I will apply it blankly, only that I will review it. ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-04-25 13:02 Message: Logged In: YES user_id=6324 If I create a patch that operates as described in my previous followup, will you apply it? Is there anything I can do to get this integrated into the main python trunk? I don't like having to repatch and rebuild python everytime a new version comes out that I need for some other reason :> ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-02-05 10:21 Message: Logged In: YES user_id=6324 1) Well, it lets python treat sys.stdin as a tty even if C stdin != python sys.stdin. It still checks to make sure sys.stdin is a tty using isatty(). If some user changes sys.stdin to point to a tty, but *wants* Python to treat it as a non-tty, then this might cause them some grief. I can't think of any case where they'd want to do that, though. The behavior would be unchanged when sys.stdin points to a regular file. 2) hmm.. I suppose, ideally, the readline module should smoothly handle sys.stdin being changed out from under it. Readline alters various terminal settings on rl_instream during initialization, though. For example, it changes the terminal to raw or cbreak mode from cooked mode, so that it can receive input a character at a time instead of a line at a time. It may be possible to uninitialized and reinitialized terminal each time call_readline is called, I suppose (I believe libreadline provides hooks for this). It would also have to check if sys.stdin is a tty, and call PyFile_GetLine if it is not. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-02-05 02:35 Message: Logged In: YES user_id=6656 Comments: 1) in what ways does this change existing behaviour? I can think of a few, but are there any that will inconvenience existing users 2) why not do the rl_instream = PySys_GetObject("stdin") dance in call_readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=512981&group_id=5470 From noreply@sourceforge.net Mon Oct 14 12:53:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 04:53:45 -0700 Subject: [Patches] [ python-Patches-572628 ] opt. timeouts for Queue.put() and .get() Message-ID: Patches item #572628, was opened at 2002-06-23 02:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572628&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Chris Liechti (cliechti) >Assigned to: Martin v. Löwis (loewis) Summary: opt. timeouts for Queue.put() and .get() Initial Comment: Sometimes one wants a Queue that doesn't block forever on a get() or put(). Both should be able to return after a certain time, acting like they were called non-blocking and failed. i.e get() raises the Empty exception when it times out, put() raises Full. This patch adds optional timeout arguments to these methods. The old 'block' arg is left and behaves 100% like in the old days (backwards compatibility). The new feature appears only when 'block' is true and 'timeout' is a positive number. The new code is basicaly a merge between the original Queue.py's put() and get() and threading.py's _Event.wait() --- code that's proven to work, nothing realy new here. I also added some simple tests to the test_queue.py script for the new feature. ---------------------------------------------------------------------- Comment By: Chris Liechti (cliechti) Date: 2002-10-13 21:17 Message: Logged In: YES user_id=403744 Here's the patch for the docs. I also updated the references to 0/1 to False/True in the other method descriptions. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 15:01 Message: Logged In: YES user_id=21627 Can you please provide documentation changes (for libqueue.tex) as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572628&group_id=5470 From noreply@sourceforge.net Mon Oct 14 12:56:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 04:56:10 -0700 Subject: [Patches] [ python-Patches-621891 ] tkFileDialog multiple option Message-ID: Patches item #621891, was opened at 2002-10-11 16:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621891&group_id=5470 Category: Tkinter Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Martin Franklin (mfranklin1) Assigned to: Nobody/Anonymous (nobody) Summary: tkFileDialog multiple option Initial Comment: In tk8.4 tk_getOpenFile and tk_getSaveFile dialogs used by tkFileDialog.py now allow the multiple option on all platforms, according to the docs... I have only tested in Linux (RedHat 7.2) python 2.2.1 and tk 8.4 This patch adds two new functions to the tkFileDialog module askopenfilenames() and askopenfiles() the function doc strings explain what they do... I've uploaded a diff. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-14 13:56 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as tkFileDialog.py 1.8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=621891&group_id=5470 From noreply@sourceforge.net Mon Oct 14 21:39:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 13:39:47 -0700 Subject: [Patches] [ python-Patches-622704 ] core setup.py - platform error msg Message-ID: Patches item #622704, was opened at 2002-10-13 15:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=622704&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: David Rushby (woodsplitter) Assigned to: Nobody/Anonymous (nobody) Summary: core setup.py - platform error msg Initial Comment: I initially submitted this as a bug report; it has been discussed here: http://sourceforge.net/tracker/index.php? func=detail&aid=620364&group_id=5470&atid=105470 As Guido requested, I'm submitting "an actual patch in context diff format". This patch is against the latest CVS version (MAIN branch, rev 1.111) of setup.py. I tar-gz'ed the patch to prevent Windows from corrupting the newlines. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-14 16:39 Message: Logged In: YES user_id=6380 I'll check in a similar test, but no 5-line error message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=622704&group_id=5470 From noreply@sourceforge.net Tue Oct 15 13:57:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Oct 2002 05:57:19 -0700 Subject: [Patches] [ python-Patches-535335 ] 2.2 patches for BSD/OS 5.0 Message-ID: Patches item #535335, was opened at 2002-03-26 13:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=535335&group_id=5470 Category: Build Group: Python 2.2.x >Status: Open Resolution: Rejected Priority: 5 Submitted By: Jeffrey Honig (jchonig) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2 patches for BSD/OS 5.0 Initial Comment: The following patches were necessary to get Python 2.2 to work on BSD/OS 5.0. More may follow as we are still attempting to resolve some issues related to the regression tests (although these may be OS issues). Thanks. Jeff ---------------------------------------------------------------------- >Comment By: Jeffrey Honig (jchonig) Date: 2002-10-15 08:57 Message: Logged In: YES user_id=96862 Sorry about my lack of response. Work is busy. Just ignore the changes to regrtest.py and the rest of the changes are fine. We'll report more next time we have a chance to run the regression tests. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 17:19 Message: Logged In: YES user_id=21627 Rejecting the patch because of inactivity. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-22 23:22 Message: Logged In: YES user_id=33168 Jeff, any chances of getting updates for this patch? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 04:49 Message: Logged In: YES user_id=21627 Is an update of this patch forthcoming? ---------------------------------------------------------------------- Comment By: Jeffrey Honig (jchonig) Date: 2002-03-26 14:08 Message: Logged In: YES user_id=96862 Re: configure.in vs configure: we don't use autoconf here so modifying configure.in doesn't help us. I should have copies the changes and submitted them, but then they aren't too hard to figure out.... Re: contrib{lib/include}: We install many of the packages that we install from the net (which we call contrib packages) into the /usr/contrib heirarchy. They won't be found by setup.py unless those paths are present. Re: regrtest.py: Apologies about the regrtest.py content, there are some tests in there that shouldn't be, ignore it for now, I'll submit an update later. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-03-26 13:53 Message: Logged In: YES user_id=33168 Lib/posixfile.py & Lib/test/test_fcntl.py seem harmless. configure is generated, so configure.in will need the changes made to it. There seem to be many tests which fail, but perhaps shouldn't: fork1, locale, minidom, poll, pyexpat, sax, unicode_file? I'm also unsure of the benefit of adding contrib/{lib/include} to setup.py. This could be fine, but I don't know anything about distutils. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=535335&group_id=5470 From noreply@sourceforge.net Tue Oct 15 16:12:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Oct 2002 08:12:12 -0700 Subject: [Patches] [ python-Patches-572628 ] opt. timeouts for Queue.put() and .get() Message-ID: Patches item #572628, was opened at 2002-06-23 02:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572628&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Chris Liechti (cliechti) Assigned to: Martin v. Löwis (loewis) Summary: opt. timeouts for Queue.put() and .get() Initial Comment: Sometimes one wants a Queue that doesn't block forever on a get() or put(). Both should be able to return after a certain time, acting like they were called non-blocking and failed. i.e get() raises the Empty exception when it times out, put() raises Full. This patch adds optional timeout arguments to these methods. The old 'block' arg is left and behaves 100% like in the old days (backwards compatibility). The new feature appears only when 'block' is true and 'timeout' is a positive number. The new code is basicaly a merge between the original Queue.py's put() and get() and threading.py's _Event.wait() --- code that's proven to work, nothing realy new here. I also added some simple tests to the test_queue.py script for the new feature. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-15 17:12 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as Queue.py 1.17; test_queue.py 1.3; libqueue.tex 1.13; NEWS 1.501; ---------------------------------------------------------------------- Comment By: Chris Liechti (cliechti) Date: 2002-10-13 21:17 Message: Logged In: YES user_id=403744 Here's the patch for the docs. I also updated the references to 0/1 to False/True in the other method descriptions. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 15:01 Message: Logged In: YES user_id=21627 Can you please provide documentation changes (for libqueue.tex) as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572628&group_id=5470 From noreply@sourceforge.net Tue Oct 15 16:26:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Oct 2002 08:26:59 -0700 Subject: [Patches] [ python-Patches-599836 ] Bugfix for urllib2.py Message-ID: Patches item #599836, was opened at 2002-08-25 00:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599836&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Closed Resolution: Fixed Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Jeremy Hylton (jhylton) Summary: Bugfix for urllib2.py Initial Comment: OpenerDirector has a default User-agent header. That wouldn't be a problem, except that AbstractHTTPHandler uses the headers in OpenerDirector.addheaders *after* a Request has been instantiated, thus making that default override whatever headers were given to Request. This patch checks to make sure a header isn't already in a Request before adding the OpenerDirector's headers. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-10-15 08:26 Message: Logged In: NO Could you also patch "urllib.py"? If you don't want to, please add an explanation here. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-10-13 07:32 Message: Logged In: NO Please also patch "urllib2.py" not only "urllib.py" --- python/dist/src/Lib/urllib.py +++ python/dist/src/Lib/urllib.py @@ -104,7 +104,7 @@ self.proxies = proxies self.key_file = x509.get('key_file') self.cert_file = x509.get('cert_file') - self.addheaders = [('User-agent', self.version)] + self.addheaders = [('User-Agent', self.version)] self.__tempfiles = [] self.__unlink = os.unlink # See cleanup() self.tempcache = None ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 10:27 Message: Logged In: YES user_id=31392 Fixed in rev 1.36. Changed case, even though the headers aren't case sensitive. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-10 11:17 Message: Logged In: NO Is there any reasons to not use the same case as Mozilla, IE and the RFC in the User-Agent HTTP header? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-06 08:50 Message: Logged In: NO Unless you want problems, I suggest you to use the same case as Mozilla, IE and the RFC in the User-Agent HTTP header. --- python/dist/src/Lib/urllib.py +++ python/dist/src/Lib/urllib.py @@ -104,7 +104,7 @@ self.proxies = proxies self.key_file = x509.get('key_file') self.cert_file = x509.get('cert_file') - self.addheaders = [('User-agent', self.version)] + self.addheaders = [('User-Agent', self.version)] self.__tempfiles = [] self.__unlink = os.unlink # See cleanup() self.tempcache = None --- python/dist/src/Lib/urllib2.py +++ python/dist/src/Lib/urllib2.py @@ -247,7 +247,7 @@ class OpenerDirector: def __init__(self): server_version = "Python-urllib/%s" % __version__ - self.addheaders = [('User-agent', server_version)] + self.addheaders = [('User-Agent', server_version)] # manage the individual handlers self.handlers = [] self.handle_open = {} ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 11:56 Message: Logged In: YES user_id=6380 For Jeremy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599836&group_id=5470 From noreply@sourceforge.net Tue Oct 15 17:03:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Oct 2002 09:03:04 -0700 Subject: [Patches] [ python-Patches-533008 ] specifying headers for extensions Message-ID: Patches item #533008, was opened at 2002-03-21 12:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=533008&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Jeremy Hylton (jhylton) Summary: specifying headers for extensions Initial Comment: This patch allows to specify that C header files are part of source files for dependency checking. The 'sources' list in Extension instances can be simple filenames as before, but they can also be SourceFile instances created by SourceFile("myfile.c", headers=["inc1.h", "inc2.h"]). Unfortunately not only changes to command.build_ext and command.build_clib had to be made, also all the ccompiler (sub)classes have to be changed because the ccompiler does the actual dependency checking. I updated all the ccompiler subclasses except mwerkscompiler.py, but only msvccompiler has actually been tested. The argument list which dep_util.newer_pairwise() now accepts has changed, the first arg must now be a sequence of SourceFile instances. This may be problematic, better would IMO be to move this function (with a new name?) into ccompiler. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-10-15 18:03 Message: Logged In: YES user_id=11105 Jeremy's solution works nicely, and is already implemented. Closing as works for me. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-12 22:18 Message: Logged In: YES user_id=31392 I think this approach to dependency tracking is too complicated. The recent depends argument to Extension rebuilds everything. This patch would allow individual .o files to be rebuilt, but at the expense of complicating the list of sources too much. Perhaps a compromise would be to use depends to specify either a list of global dependencies or a list of per-file dependencies specified as a pair containing a filename and a list. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-12 22:13 Message: Logged In: YES user_id=3066 Assigned to Jeremy since he's dealing with this issue today. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-24 20:28 Message: Logged In: YES user_id=11105 Shouldn't holdup any release. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-25 19:13 Message: Logged In: YES user_id=11105 This patch has two problems: - it is too large, - it breaks custom subclasses of distutils' build command family. I have two of them in my setup scripts, there are probably more out in the world. Here is an idea for a totally different approach: The checking whether targets needs to be rebuild is done with the newer_group() and newer_pairwise() functions in distutils.dep_util. These methods could scan the source-files for include directives and user the timestamps of the include files as well. This patch would be fairly small. OTOH, I have no C-source scanner lying around, and also don't feel to write one. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-04 21:57 Message: Logged In: YES user_id=3066 Wow! That's certainly more patch than I'd expected, but the approach looks about right to me. I'd like to take another look at it in a few days (mail me if I don't take action soon) before we accept, just to make sure I understand it better. Thanks! ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-03-25 10:03 Message: Logged In: YES user_id=11105 Fred requested it this way: http://mail.python.org/pipermail/distutils-sig/2002- March/002806.html ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-24 23:05 Message: Logged In: YES user_id=6380 Why is this priority 7?????? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=533008&group_id=5470 From noreply@sourceforge.net Tue Oct 15 18:13:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Oct 2002 10:13:57 -0700 Subject: [Patches] [ python-Patches-614770 ] MSVC 7.0 compiler support Message-ID: Patches item #614770, was opened at 2002-09-26 05:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614770&group_id=5470 Category: Distutils and setup.py Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: John Anderson (djohnanderson) Assigned to: Nobody/Anonymous (nobody) Summary: MSVC 7.0 compiler support Initial Comment: Distutils doesn't work with the current shipping version of the Microsoft compiler (7.0). I've got a patch that fixes it (context diffs of msvccompiler.py against the latest code in CVS). ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-10-15 19:13 Message: Logged In: YES user_id=11105 I've tried out the patch, and it works for me, at least with simple extensions - both with MSVC 6 and with MSVC 7, freshly installed. I don't know the service pack level of my MSVC6, Help- >About doesn't show it. I'm not sure if using 7.0 (if available) should be the default. Python itself is still built with MSVC6 AFAIK. ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-10-08 17:51 Message: Logged In: YES user_id=618290 Thanks Martin for taking the time to review my proposed changes. I think your comments about looking in Software\Microsoft\VisualStudio instead of Software\Microsoft\DevStudio is a good point. I decided to two look only in VisualStudio because that works for both the version 6 and 7 compiler I tested with. I don't know if the version 5 compiler also stores the version in DevStudio. Another alternative, which would of course complicate code, would be two look in both places and choose the highest version. Let me know if that's what you'd prefer and I'll upload a new patch. The problem I'm having with the version 6 compiler (latest service Pack 5) is that SOFTWARE\Microsoft\Devstudio\6.0\Build System\ doesn't exist. Instead it looks like it's been moved to SOFTWARE\Microsoft\Shared Tools\Build System\, but in that new location, SOFTWARE\Microsoft\Shared Tools\Build System\Components\Platforms\Win32 (x86)\Directories doesn't exist. This has the effect of not getting the correct include directories for builds. This also points out a serious flaw in looking at undocumented registry entries to find information for the build -- there's no guarantee that the registry information won't change even within the same version of the compiler. I don't have a good solution for this problem, but I'd rather distutils reported an error when it couldn't find the registry entries it expected -- rather than silently ignoring it as it does now. In a few places I added code to report unexpected missing registry entries, but not all. I could if you're interested add error code in all cases. Fixing the problem I'm having with the version 6 compiler seems difficult, since it seems to work for you and doesn't work for me -- apparently are registries are different. Personally I'm content with leaving the version 6 compiler broken since it isn't obvious how to fix it and it apparently works for some people and I only intend to use the version 7 or newer compilers. I added three new functions: convert_mbcs, read_key, and by far the largest: expand_macros. The first two make the code simpler, easier to read, avoid unnecessary duplications, and minimize the risk that someone would forget to deal with mbcs. It would be difficult to understand the bug fix without these two functions. My hope was that these changes would make it easier for the next person who needs to learn the code. The last, expand_macros, is necessary because the version 7 compiler introduces macros which didn't exist in previous versions of the compiler. It would be awkward to implement the macros without having adding a new function. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-08 11:21 Message: Logged In: YES user_id=21627 I'm asking because you are not looking into Software\Microsoft\Devstudio anymore to find the most recent version. Not supporting MSVC5 anymore is probably acceptable. I never noticed that support for MSVC6 is broken - it works fine for me... However, if you think you can improve that somehow, please do - please elaborate what changes solve what problems, though. It seems that a number of changes are not strictly necessary (e.g. creation of new functions), to really evaluate the patch, I have to know why you propose these changes. ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-10-07 17:27 Message: Logged In: YES user_id=618290 It's been so long since I had a copy of MSVC 5 -- I think it became obsolete about 6 or 7 years ago. None of my changes should have any impact on the operation of MSVC 5, but of course you never know unless you try it. Also, the MSVC 6 support in distutils is currently broken -- although it finds the compiler, the code to find the include paths is totally broken. I have MSVC 6 (latest service pack) and 7 and would be willing to make both those work. Anyone who's using 5 is going to have lots of other problems to deal with besides distutils. Wouldn't surprise me if the MSVC 6 code for finding paths would differ in each service pack -- since it depends upon unsupported registry entries. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 13:43 Message: Logged In: YES user_id=21627 Can you report whether this patch works with MSVC 5? ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-09-26 23:38 Message: Logged In: YES user_id=618290 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-09-26 23:38 Message: Logged In: YES user_id=618290 Opps, I guess I forgot to check that little box. Sorry about that. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 06:30 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614770&group_id=5470 From noreply@sourceforge.net Tue Oct 15 20:43:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Oct 2002 12:43:37 -0700 Subject: [Patches] [ python-Patches-613256 ] add unescape method to xml.sax.saxutils Message-ID: Patches item #613256, was opened at 2002-09-23 11:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613256&group_id=5470 Category: XML Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Boedicker (mboedick) Assigned to: Martin v. Löwis (loewis) Summary: add unescape method to xml.sax.saxutils Initial Comment: This patch adds an unescape() method to saxutils to convert an xml-escaped string back to its original form It also modifies the escape() method so that the core escaping takes places after any additional escaping passed in via the dictionary. This will guarantee that returned string is properly escaped for xml no matter what is passed in via the dictionary. ---------------------------------------------------------------------- >Comment By: Matthew Boedicker (mboedick) Date: 2002-10-15 15:43 Message: Logged In: YES user_id=119895 added documentation and test cases no longer changes the order in which escape() modifies the string with core and passed-in replacements ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 08:53 Message: Logged In: YES user_id=21627 Can you please provide documentation and test cases? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613256&group_id=5470 From noreply@sourceforge.net Tue Oct 15 22:01:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Oct 2002 14:01:32 -0700 Subject: [Patches] [ python-Patches-614770 ] MSVC 7.0 compiler support Message-ID: Patches item #614770, was opened at 2002-09-25 23:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614770&group_id=5470 Category: Distutils and setup.py Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: John Anderson (djohnanderson) Assigned to: Nobody/Anonymous (nobody) Summary: MSVC 7.0 compiler support Initial Comment: Distutils doesn't work with the current shipping version of the Microsoft compiler (7.0). I've got a patch that fixes it (context diffs of msvccompiler.py against the latest code in CVS). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-10-15 17:01 Message: Logged In: YES user_id=31435 Thomas, I'm just curious here: if we were to create the Windows Python distribution with VC7, would the DLLs be compatible with extensions compiled by VC6? In return for your answer to that , here's how to determine your MSVC6 service pack level: HKLM\ SOFTWARE\ Microsoft\ VisualStudio\ 6.0\ ServicePacks and look at key "latest". ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-10-15 13:13 Message: Logged In: YES user_id=11105 I've tried out the patch, and it works for me, at least with simple extensions - both with MSVC 6 and with MSVC 7, freshly installed. I don't know the service pack level of my MSVC6, Help- >About doesn't show it. I'm not sure if using 7.0 (if available) should be the default. Python itself is still built with MSVC6 AFAIK. ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-10-08 11:51 Message: Logged In: YES user_id=618290 Thanks Martin for taking the time to review my proposed changes. I think your comments about looking in Software\Microsoft\VisualStudio instead of Software\Microsoft\DevStudio is a good point. I decided to two look only in VisualStudio because that works for both the version 6 and 7 compiler I tested with. I don't know if the version 5 compiler also stores the version in DevStudio. Another alternative, which would of course complicate code, would be two look in both places and choose the highest version. Let me know if that's what you'd prefer and I'll upload a new patch. The problem I'm having with the version 6 compiler (latest service Pack 5) is that SOFTWARE\Microsoft\Devstudio\6.0\Build System\ doesn't exist. Instead it looks like it's been moved to SOFTWARE\Microsoft\Shared Tools\Build System\, but in that new location, SOFTWARE\Microsoft\Shared Tools\Build System\Components\Platforms\Win32 (x86)\Directories doesn't exist. This has the effect of not getting the correct include directories for builds. This also points out a serious flaw in looking at undocumented registry entries to find information for the build -- there's no guarantee that the registry information won't change even within the same version of the compiler. I don't have a good solution for this problem, but I'd rather distutils reported an error when it couldn't find the registry entries it expected -- rather than silently ignoring it as it does now. In a few places I added code to report unexpected missing registry entries, but not all. I could if you're interested add error code in all cases. Fixing the problem I'm having with the version 6 compiler seems difficult, since it seems to work for you and doesn't work for me -- apparently are registries are different. Personally I'm content with leaving the version 6 compiler broken since it isn't obvious how to fix it and it apparently works for some people and I only intend to use the version 7 or newer compilers. I added three new functions: convert_mbcs, read_key, and by far the largest: expand_macros. The first two make the code simpler, easier to read, avoid unnecessary duplications, and minimize the risk that someone would forget to deal with mbcs. It would be difficult to understand the bug fix without these two functions. My hope was that these changes would make it easier for the next person who needs to learn the code. The last, expand_macros, is necessary because the version 7 compiler introduces macros which didn't exist in previous versions of the compiler. It would be awkward to implement the macros without having adding a new function. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-08 05:21 Message: Logged In: YES user_id=21627 I'm asking because you are not looking into Software\Microsoft\Devstudio anymore to find the most recent version. Not supporting MSVC5 anymore is probably acceptable. I never noticed that support for MSVC6 is broken - it works fine for me... However, if you think you can improve that somehow, please do - please elaborate what changes solve what problems, though. It seems that a number of changes are not strictly necessary (e.g. creation of new functions), to really evaluate the patch, I have to know why you propose these changes. ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-10-07 11:27 Message: Logged In: YES user_id=618290 It's been so long since I had a copy of MSVC 5 -- I think it became obsolete about 6 or 7 years ago. None of my changes should have any impact on the operation of MSVC 5, but of course you never know unless you try it. Also, the MSVC 6 support in distutils is currently broken -- although it finds the compiler, the code to find the include paths is totally broken. I have MSVC 6 (latest service pack) and 7 and would be willing to make both those work. Anyone who's using 5 is going to have lots of other problems to deal with besides distutils. Wouldn't surprise me if the MSVC 6 code for finding paths would differ in each service pack -- since it depends upon unsupported registry entries. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 07:43 Message: Logged In: YES user_id=21627 Can you report whether this patch works with MSVC 5? ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-09-26 17:38 Message: Logged In: YES user_id=618290 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-09-26 17:38 Message: Logged In: YES user_id=618290 Opps, I guess I forgot to check that little box. Sorry about that. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 00:30 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614770&group_id=5470 From noreply@sourceforge.net Tue Oct 15 22:30:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Oct 2002 14:30:36 -0700 Subject: [Patches] [ python-Patches-623771 ] autoconf-2.5X tweaks for configure.in Message-ID: Patches item #623771, was opened at 2002-10-15 16:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=623771&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Art Haas (ahaas) Assigned to: Nobody/Anonymous (nobody) Summary: autoconf-2.5X tweaks for configure.in Initial Comment: Hi. Here's a small patch that adjust AC_INIT and AC_OUTPUT from the autoconf-2.13 style to the new autoconf-2.5X style. In changing these macros to their new format, the addition of AC_CONFIG_SRCDIR and AC_CONFIG_FILES is required. I've also removed the VERSION macro as that value can be defined in the second argument of AC_INIT. Art Haas ahaas@neosoft.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=623771&group_id=5470 From noreply@sourceforge.net Tue Oct 15 22:31:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Oct 2002 14:31:52 -0700 Subject: [Patches] [ python-Patches-614055 ] OpenVMS patches Message-ID: Patches item #614055, was opened at 2002-09-24 23:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614055&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Piéronne Jean-François (pieronne) Assigned to: Nobody/Anonymous (nobody) Summary: OpenVMS patches Initial Comment: The attach file contains the patches of the Core files necessary to build Python for OpenVMS. All the patches used conditional compilation test on __VMS, so I may not be disruptive for the initial code. 11 files have been updated: Python/exceptions.c Python/import.c Modules/getbuildinfo.c Modules/getpatch.c Modules/main.c Modules/posixmodule.c Modules/pwdmodule.c Modules/socketmodule.c Modules/stringobject.c Modules/_hotshot.c include/pyerrors.h Jean-François ---------------------------------------------------------------------- >Comment By: Piéronne Jean-François (pieronne) Date: 2002-10-15 23:31 Message: Logged In: YES user_id=414701 A new version which apply on Sunday snap ---------------------------------------------------------------------- Comment By: Piéronne Jean-François (pieronne) Date: 2002-10-03 13:57 Message: Logged In: YES user_id=414701 After testing using 20002-10-03_070000 some patches failed, This new version apply correctly. Jean-François ---------------------------------------------------------------------- Comment By: Piéronne Jean-François (pieronne) Date: 2002-10-03 09:38 Message: Logged In: YES user_id=414701 I have attach a new version(vms02.diff) using the latest CVS snapshot, I have also slightly update patch of main.c Thanks, Jean-François ---------------------------------------------------------------------- Comment By: Piéronne Jean-François (pieronne) Date: 2002-09-25 22:03 Message: Logged In: YES user_id=414701 Comment seem to be missing. VMSerror is used by many specifics module which I have not currently provide. I have correct the typo VMSerror --> VMSError formatting problem: Well, this is the formatting used by Uwe Zessin (and mostly generate by the editor LSE) who has done the initial port. I have not check/update his code because I did'nt know it is required, I have just found the "Style Guide for C Code". I have now update the code, only the VMS part ;-) Compute of the link time: Really necessary, sure it is not. But, IMHO, it is more useful to have the link time than the compile time of one source file. What is the problem? psxmod_gat_psxpath, psxmod_to_vms_action: You are right. During the cleaning process of the code of Uwe (I have remove some part), I have missed this optimisation and to remove the, then, unused routine psxmod_to_vms. Done, thanks. I have attach a new version: vms01.diff Tell me if you find other problem into this version. Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-25 15:02 Message: Logged In: YES user_id=21627 I have a number of comments and questions: - What is the purpose of VMSerror? It appears to be unused. Can you use just OSError instead? If not, it should be VMSError. - There are various formatting problems (indentation, spaces after function names). - Is it really necessary to compute the link time? - Why do you need psxmod_gat_psxpath? Copying into psxmod_gt_psxpath appears to do the same thing? - what is the purpose of psxmod_to_vms_action? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614055&group_id=5470 From noreply@sourceforge.net Tue Oct 15 22:45:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Oct 2002 14:45:40 -0700 Subject: [Patches] [ python-Patches-623780 ] configure.in obsolete macro replacement Message-ID: Patches item #623780, was opened at 2002-10-15 16:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=623780&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Art Haas (ahaas) Assigned to: Nobody/Anonymous (nobody) Summary: configure.in obsolete macro replacement Initial Comment: Hi. Here's a patch that replaces the obsolete AC_STRUCT_ST_RDEV and AC_STRUCT_ST_BLKSIZE macros with their new counterparts from AC_CHECK_MEMBERS. In replacing these two macros, the pyconfig.h.in file had the deprecated definitions for these two macros removed as well as the deprecated form for the AC_STRUCT_ST_BLOCKS macro, and the associated changes to posixmodule.c to test for the new preprocessor definitions were added. While fiddling with pyconfig.h.in, I also removed the deprecated form for time zone macros, and made a change to the timemodule.c file so it will use the new preprocessor token. I've rebuilt my python with these changes and it looks alright. The line numbers for the configure.in patch may be a little off as I've modified it slightly by changing the AC_INIT macro - there is a patch submitted for that change as well. Art Haas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=623780&group_id=5470 From noreply@sourceforge.net Wed Oct 16 02:55:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Oct 2002 18:55:01 -0700 Subject: [Patches] [ python-Patches-617779 ] Rational Reference Implementation Message-ID: Patches item #617779, was opened at 2002-10-02 17:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617779&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christopher A. Craig (ccraig) Assigned to: Nobody/Anonymous (nobody) Summary: Rational Reference Implementation Initial Comment: This is a reference implementation of rational numbers (PEP239). It includes regression tests for rationals and changes to cPickle/pickle to support them. It has been tested on Solaris and Linux, but notably not Windows. This implementation does change the behaviour of future division to return a rational rather than a float. ---------------------------------------------------------------------- >Comment By: Christopher A. Craig (ccraig) Date: 2002-10-15 21:55 Message: Logged In: YES user_id=135050 Attached rational-Nr uses rational literals in the form 3r or 3R ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617779&group_id=5470 From noreply@sourceforge.net Wed Oct 16 09:20:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Oct 2002 01:20:53 -0700 Subject: [Patches] [ python-Patches-614770 ] MSVC 7.0 compiler support Message-ID: Patches item #614770, was opened at 2002-09-26 05:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614770&group_id=5470 Category: Distutils and setup.py Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: John Anderson (djohnanderson) Assigned to: Nobody/Anonymous (nobody) Summary: MSVC 7.0 compiler support Initial Comment: Distutils doesn't work with the current shipping version of the Microsoft compiler (7.0). I've got a patch that fixes it (context diffs of msvccompiler.py against the latest code in CVS). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-16 10:20 Message: Logged In: YES user_id=21627 The biggest problem is that VC.NET uses a new C library, msvcr70[d].dll. I have not fully studied all issues, but it appears that, for purposes of Python, you cannot mix extensions, atleast not in the general case. In particular, you cannot pass FILE* between both C libraries. This is particularly annoying, since MS has managed that struct _iobuf (aka FILE) has identical layout in both compilers. Nevertheless, it crashes in the following scenario: VC7:fopen VC: fputs The problem is that fputs wants to lock the file. For that, it tests whether the pointer comes from its own _iob (_file.c:_lock_file). If the pointer comes from the _iob of the other C library, it concludes that this must be a _FILEX (which it isn't), and crashes :-( So it appears that one *must* build extension modules with the Visual Studio that also has built Python. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-10-15 23:01 Message: Logged In: YES user_id=31435 Thomas, I'm just curious here: if we were to create the Windows Python distribution with VC7, would the DLLs be compatible with extensions compiled by VC6? In return for your answer to that , here's how to determine your MSVC6 service pack level: HKLM\ SOFTWARE\ Microsoft\ VisualStudio\ 6.0\ ServicePacks and look at key "latest". ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-10-15 19:13 Message: Logged In: YES user_id=11105 I've tried out the patch, and it works for me, at least with simple extensions - both with MSVC 6 and with MSVC 7, freshly installed. I don't know the service pack level of my MSVC6, Help- >About doesn't show it. I'm not sure if using 7.0 (if available) should be the default. Python itself is still built with MSVC6 AFAIK. ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-10-08 17:51 Message: Logged In: YES user_id=618290 Thanks Martin for taking the time to review my proposed changes. I think your comments about looking in Software\Microsoft\VisualStudio instead of Software\Microsoft\DevStudio is a good point. I decided to two look only in VisualStudio because that works for both the version 6 and 7 compiler I tested with. I don't know if the version 5 compiler also stores the version in DevStudio. Another alternative, which would of course complicate code, would be two look in both places and choose the highest version. Let me know if that's what you'd prefer and I'll upload a new patch. The problem I'm having with the version 6 compiler (latest service Pack 5) is that SOFTWARE\Microsoft\Devstudio\6.0\Build System\ doesn't exist. Instead it looks like it's been moved to SOFTWARE\Microsoft\Shared Tools\Build System\, but in that new location, SOFTWARE\Microsoft\Shared Tools\Build System\Components\Platforms\Win32 (x86)\Directories doesn't exist. This has the effect of not getting the correct include directories for builds. This also points out a serious flaw in looking at undocumented registry entries to find information for the build -- there's no guarantee that the registry information won't change even within the same version of the compiler. I don't have a good solution for this problem, but I'd rather distutils reported an error when it couldn't find the registry entries it expected -- rather than silently ignoring it as it does now. In a few places I added code to report unexpected missing registry entries, but not all. I could if you're interested add error code in all cases. Fixing the problem I'm having with the version 6 compiler seems difficult, since it seems to work for you and doesn't work for me -- apparently are registries are different. Personally I'm content with leaving the version 6 compiler broken since it isn't obvious how to fix it and it apparently works for some people and I only intend to use the version 7 or newer compilers. I added three new functions: convert_mbcs, read_key, and by far the largest: expand_macros. The first two make the code simpler, easier to read, avoid unnecessary duplications, and minimize the risk that someone would forget to deal with mbcs. It would be difficult to understand the bug fix without these two functions. My hope was that these changes would make it easier for the next person who needs to learn the code. The last, expand_macros, is necessary because the version 7 compiler introduces macros which didn't exist in previous versions of the compiler. It would be awkward to implement the macros without having adding a new function. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-08 11:21 Message: Logged In: YES user_id=21627 I'm asking because you are not looking into Software\Microsoft\Devstudio anymore to find the most recent version. Not supporting MSVC5 anymore is probably acceptable. I never noticed that support for MSVC6 is broken - it works fine for me... However, if you think you can improve that somehow, please do - please elaborate what changes solve what problems, though. It seems that a number of changes are not strictly necessary (e.g. creation of new functions), to really evaluate the patch, I have to know why you propose these changes. ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-10-07 17:27 Message: Logged In: YES user_id=618290 It's been so long since I had a copy of MSVC 5 -- I think it became obsolete about 6 or 7 years ago. None of my changes should have any impact on the operation of MSVC 5, but of course you never know unless you try it. Also, the MSVC 6 support in distutils is currently broken -- although it finds the compiler, the code to find the include paths is totally broken. I have MSVC 6 (latest service pack) and 7 and would be willing to make both those work. Anyone who's using 5 is going to have lots of other problems to deal with besides distutils. Wouldn't surprise me if the MSVC 6 code for finding paths would differ in each service pack -- since it depends upon unsupported registry entries. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 13:43 Message: Logged In: YES user_id=21627 Can you report whether this patch works with MSVC 5? ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-09-26 23:38 Message: Logged In: YES user_id=618290 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-09-26 23:38 Message: Logged In: YES user_id=618290 Opps, I guess I forgot to check that little box. Sorry about that. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 06:30 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614770&group_id=5470 From noreply@sourceforge.net Wed Oct 16 09:50:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Oct 2002 01:50:47 -0700 Subject: [Patches] [ python-Patches-614770 ] MSVC 7.0 compiler support Message-ID: Patches item #614770, was opened at 2002-09-26 05:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614770&group_id=5470 Category: Distutils and setup.py Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: John Anderson (djohnanderson) Assigned to: Nobody/Anonymous (nobody) Summary: MSVC 7.0 compiler support Initial Comment: Distutils doesn't work with the current shipping version of the Microsoft compiler (7.0). I've got a patch that fixes it (context diffs of msvccompiler.py against the latest code in CVS). ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-10-16 10:50 Message: Logged In: YES user_id=11105 It seems Martin is correct. I made the following experiment: Compile pythoncore, python and pythonw with MSVC7, and the remaining extension modules with MSVC6 (all, except bsddb and _tkinter). Now the test-suite crashes hard in test_parser. When everything is built with MSVC7, the test-suite runs fine. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-16 10:20 Message: Logged In: YES user_id=21627 The biggest problem is that VC.NET uses a new C library, msvcr70[d].dll. I have not fully studied all issues, but it appears that, for purposes of Python, you cannot mix extensions, atleast not in the general case. In particular, you cannot pass FILE* between both C libraries. This is particularly annoying, since MS has managed that struct _iobuf (aka FILE) has identical layout in both compilers. Nevertheless, it crashes in the following scenario: VC7:fopen VC: fputs The problem is that fputs wants to lock the file. For that, it tests whether the pointer comes from its own _iob (_file.c:_lock_file). If the pointer comes from the _iob of the other C library, it concludes that this must be a _FILEX (which it isn't), and crashes :-( So it appears that one *must* build extension modules with the Visual Studio that also has built Python. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-10-15 23:01 Message: Logged In: YES user_id=31435 Thomas, I'm just curious here: if we were to create the Windows Python distribution with VC7, would the DLLs be compatible with extensions compiled by VC6? In return for your answer to that , here's how to determine your MSVC6 service pack level: HKLM\ SOFTWARE\ Microsoft\ VisualStudio\ 6.0\ ServicePacks and look at key "latest". ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-10-15 19:13 Message: Logged In: YES user_id=11105 I've tried out the patch, and it works for me, at least with simple extensions - both with MSVC 6 and with MSVC 7, freshly installed. I don't know the service pack level of my MSVC6, Help- >About doesn't show it. I'm not sure if using 7.0 (if available) should be the default. Python itself is still built with MSVC6 AFAIK. ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-10-08 17:51 Message: Logged In: YES user_id=618290 Thanks Martin for taking the time to review my proposed changes. I think your comments about looking in Software\Microsoft\VisualStudio instead of Software\Microsoft\DevStudio is a good point. I decided to two look only in VisualStudio because that works for both the version 6 and 7 compiler I tested with. I don't know if the version 5 compiler also stores the version in DevStudio. Another alternative, which would of course complicate code, would be two look in both places and choose the highest version. Let me know if that's what you'd prefer and I'll upload a new patch. The problem I'm having with the version 6 compiler (latest service Pack 5) is that SOFTWARE\Microsoft\Devstudio\6.0\Build System\ doesn't exist. Instead it looks like it's been moved to SOFTWARE\Microsoft\Shared Tools\Build System\, but in that new location, SOFTWARE\Microsoft\Shared Tools\Build System\Components\Platforms\Win32 (x86)\Directories doesn't exist. This has the effect of not getting the correct include directories for builds. This also points out a serious flaw in looking at undocumented registry entries to find information for the build -- there's no guarantee that the registry information won't change even within the same version of the compiler. I don't have a good solution for this problem, but I'd rather distutils reported an error when it couldn't find the registry entries it expected -- rather than silently ignoring it as it does now. In a few places I added code to report unexpected missing registry entries, but not all. I could if you're interested add error code in all cases. Fixing the problem I'm having with the version 6 compiler seems difficult, since it seems to work for you and doesn't work for me -- apparently are registries are different. Personally I'm content with leaving the version 6 compiler broken since it isn't obvious how to fix it and it apparently works for some people and I only intend to use the version 7 or newer compilers. I added three new functions: convert_mbcs, read_key, and by far the largest: expand_macros. The first two make the code simpler, easier to read, avoid unnecessary duplications, and minimize the risk that someone would forget to deal with mbcs. It would be difficult to understand the bug fix without these two functions. My hope was that these changes would make it easier for the next person who needs to learn the code. The last, expand_macros, is necessary because the version 7 compiler introduces macros which didn't exist in previous versions of the compiler. It would be awkward to implement the macros without having adding a new function. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-08 11:21 Message: Logged In: YES user_id=21627 I'm asking because you are not looking into Software\Microsoft\Devstudio anymore to find the most recent version. Not supporting MSVC5 anymore is probably acceptable. I never noticed that support for MSVC6 is broken - it works fine for me... However, if you think you can improve that somehow, please do - please elaborate what changes solve what problems, though. It seems that a number of changes are not strictly necessary (e.g. creation of new functions), to really evaluate the patch, I have to know why you propose these changes. ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-10-07 17:27 Message: Logged In: YES user_id=618290 It's been so long since I had a copy of MSVC 5 -- I think it became obsolete about 6 or 7 years ago. None of my changes should have any impact on the operation of MSVC 5, but of course you never know unless you try it. Also, the MSVC 6 support in distutils is currently broken -- although it finds the compiler, the code to find the include paths is totally broken. I have MSVC 6 (latest service pack) and 7 and would be willing to make both those work. Anyone who's using 5 is going to have lots of other problems to deal with besides distutils. Wouldn't surprise me if the MSVC 6 code for finding paths would differ in each service pack -- since it depends upon unsupported registry entries. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 13:43 Message: Logged In: YES user_id=21627 Can you report whether this patch works with MSVC 5? ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-09-26 23:38 Message: Logged In: YES user_id=618290 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-09-26 23:38 Message: Logged In: YES user_id=618290 Opps, I guess I forgot to check that little box. Sorry about that. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 06:30 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614770&group_id=5470 From noreply@sourceforge.net Wed Oct 16 10:24:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Oct 2002 02:24:39 -0700 Subject: [Patches] [ python-Patches-578494 ] PEP 282 Implementation Message-ID: Patches item #578494, was opened at 2002-07-08 00:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=578494&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Vinay Sajip (vsajip) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 282 Implementation Initial Comment: The attached file implements PEP282. The file logging- 0.4.6.tar.gz is the entire distribution including setup/install, test/example scripts, and TeX documentation. The file logging.py (within the .tar.gz) is all that is needed to implement the PEP. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2002-10-16 09:24 Message: Logged In: YES user_id=308438 The logging.tar.gz is an in-between-releases version which I have uploaded for GvR review. It contains the logging module refactored as a package. __init__.py contains the core including FileHandler and StreamHandler; handlers.py contains all the other handlers; and config.py contains the file- based config stuff. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-02 21:25 Message: Logged In: YES user_id=6380 Um, Mark, looks like you accidentally closed this! I reopened it and assigned it to me for review. I'm gonna read the PEP and see if I like the design decisions enough to pronounce acceptance. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-07-10 02:22 Message: Logged In: YES user_id=14198 The code seems high quality and well documented. I have no concerns with logging.py as such. I have two main issues: * Design decisions: looking over python-dev, I can not see a consensus on the design decisions. I believe that *some* type of official acceptance of the design should be decreed by someone. * Source structure: while this seems quite suitable for an extension module, the format of the patch is probably not quite correct for a core module. For example, the test code should probably be integrated with the standard Python test suite (even if in a sub-directory), the Tex docs integrated with Python's docs etc So while I think the patch is high quality I believe these issues need to be addressed before I can do much more. Setting to "pending" - but good stuff tho! Please drive this through! ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2002-07-08 00:56 Message: Logged In: YES user_id=308438 Added just the logging.py file to make it easier to review. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=578494&group_id=5470 From noreply@sourceforge.net Wed Oct 16 11:54:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Oct 2002 03:54:42 -0700 Subject: [Patches] [ python-Patches-623771 ] autoconf-2.5X tweaks for configure.in Message-ID: Patches item #623771, was opened at 2002-10-15 21:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=623771&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Art Haas (ahaas) >Assigned to: Martin v. Löwis (loewis) Summary: autoconf-2.5X tweaks for configure.in Initial Comment: Hi. Here's a small patch that adjust AC_INIT and AC_OUTPUT from the autoconf-2.13 style to the new autoconf-2.5X style. In changing these macros to their new format, the addition of AC_CONFIG_SRCDIR and AC_CONFIG_FILES is required. I've also removed the VERSION macro as that value can be defined in the second argument of AC_INIT. Art Haas ahaas@neosoft.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=623771&group_id=5470 From noreply@sourceforge.net Wed Oct 16 11:55:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Oct 2002 03:55:10 -0700 Subject: [Patches] [ python-Patches-623780 ] configure.in obsolete macro replacement Message-ID: Patches item #623780, was opened at 2002-10-15 21:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=623780&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Art Haas (ahaas) >Assigned to: Martin v. Löwis (loewis) Summary: configure.in obsolete macro replacement Initial Comment: Hi. Here's a patch that replaces the obsolete AC_STRUCT_ST_RDEV and AC_STRUCT_ST_BLKSIZE macros with their new counterparts from AC_CHECK_MEMBERS. In replacing these two macros, the pyconfig.h.in file had the deprecated definitions for these two macros removed as well as the deprecated form for the AC_STRUCT_ST_BLOCKS macro, and the associated changes to posixmodule.c to test for the new preprocessor definitions were added. While fiddling with pyconfig.h.in, I also removed the deprecated form for time zone macros, and made a change to the timemodule.c file so it will use the new preprocessor token. I've rebuilt my python with these changes and it looks alright. The line numbers for the configure.in patch may be a little off as I've modified it slightly by changing the AC_INIT macro - there is a patch submitted for that change as well. Art Haas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=623780&group_id=5470 From noreply@sourceforge.net Wed Oct 16 12:22:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Oct 2002 04:22:10 -0700 Subject: [Patches] [ python-Patches-623771 ] autoconf-2.5X tweaks for configure.in Message-ID: Patches item #623771, was opened at 2002-10-15 23:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=623771&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Art Haas (ahaas) Assigned to: Martin v. Löwis (loewis) Summary: autoconf-2.5X tweaks for configure.in Initial Comment: Hi. Here's a small patch that adjust AC_INIT and AC_OUTPUT from the autoconf-2.13 style to the new autoconf-2.5X style. In changing these macros to their new format, the addition of AC_CONFIG_SRCDIR and AC_CONFIG_FILES is required. I've also removed the VERSION macro as that value can be defined in the second argument of AC_INIT. Art Haas ahaas@neosoft.com ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-16 13:22 Message: Logged In: YES user_id=21627 It appears that you did not test this change. AC_INIT does not define VERSION, but PACKAGE_VERSION. Even if this is fixed (somehow), the resulting pyconfig.h will be installed, and then conflict in its PACKAGE_VERSION definition with other packages which also use autoconf. So I'm not sure this should be done at all. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=623771&group_id=5470 From noreply@sourceforge.net Wed Oct 16 13:26:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Oct 2002 05:26:11 -0700 Subject: [Patches] [ python-Patches-623780 ] configure.in obsolete macro replacement Message-ID: Patches item #623780, was opened at 2002-10-15 23:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=623780&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Art Haas (ahaas) Assigned to: Martin v. Löwis (loewis) Summary: configure.in obsolete macro replacement Initial Comment: Hi. Here's a patch that replaces the obsolete AC_STRUCT_ST_RDEV and AC_STRUCT_ST_BLKSIZE macros with their new counterparts from AC_CHECK_MEMBERS. In replacing these two macros, the pyconfig.h.in file had the deprecated definitions for these two macros removed as well as the deprecated form for the AC_STRUCT_ST_BLOCKS macro, and the associated changes to posixmodule.c to test for the new preprocessor definitions were added. While fiddling with pyconfig.h.in, I also removed the deprecated form for time zone macros, and made a change to the timemodule.c file so it will use the new preprocessor token. I've rebuilt my python with these changes and it looks alright. The line numbers for the configure.in patch may be a little off as I've modified it slightly by changing the AC_INIT macro - there is a patch submitted for that change as well. Art Haas ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-16 14:26 Message: Logged In: YES user_id=21627 Can you please point to the documentation that declares those macros as obsolete? I could only find that AC_ST_RDEV is obsolete, and replaced by AC_STRUCT_ST_RDEV. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=623780&group_id=5470 From noreply@sourceforge.net Wed Oct 16 17:16:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Oct 2002 09:16:20 -0700 Subject: [Patches] [ python-Patches-624180 ] HTTP Auth support for xmlrpclib Message-ID: Patches item #624180, was opened at 2002-10-16 16:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=624180&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Phillip J. Eby (pje) Assigned to: Nobody/Anonymous (nobody) Summary: HTTP Auth support for xmlrpclib Initial Comment: This patch adds code and docs to support the use of HTTP/HTTPS "Basic Authorization" with xmlrpclib. It does this using the "http://user:pass@host:port/" syntax, based on existing code in urllib and xmlrpclib. I have tested the code change with and without basic auth on my own servers, but do not know how I could create a reasonable addition to the test suite, since a server connection would be required. My patch includes a patch to Doc/lib/libxmlrpclib.tex, but I'm not sure if I added the text in the best place. It may be that it should be a note in the 'seealso' section on that page instead, but I wasn't sure if that was correct style for the library documentation. For the code patch, I tried to match the style of the surrounding code as closely as possible, including the style used for code comments. The patch is against current (as of this moment) Python CVS. Please let me know if there's any other info you need or anything that I should change for this. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=624180&group_id=5470 From noreply@sourceforge.net Wed Oct 16 17:44:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Oct 2002 09:44:21 -0700 Subject: [Patches] [ python-Patches-623771 ] autoconf-2.5X tweaks for configure.in Message-ID: Patches item #623771, was opened at 2002-10-15 16:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=623771&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Art Haas (ahaas) Assigned to: Martin v. Löwis (loewis) Summary: autoconf-2.5X tweaks for configure.in Initial Comment: Hi. Here's a small patch that adjust AC_INIT and AC_OUTPUT from the autoconf-2.13 style to the new autoconf-2.5X style. In changing these macros to their new format, the addition of AC_CONFIG_SRCDIR and AC_CONFIG_FILES is required. I've also removed the VERSION macro as that value can be defined in the second argument of AC_INIT. Art Haas ahaas@neosoft.com ---------------------------------------------------------------------- >Comment By: Art Haas (ahaas) Date: 2002-10-16 11:44 Message: Logged In: YES user_id=629911 Hi. I did test this, and it worked fine - as far as I could tell. The autoconf docs I have (autoconf-2.54) show that AC_INIT is defined like ... AC_INIT (PACKAGE, VERSION, [BUG-REPORT], [TARNAME]) ... and PACKAGE_VERSION is taken from VERSION. I suppose that if there is a conflict, then the variable VERSION can be directly defined after AC_INIT, and it can be specified to whatever is needed to avoid the problems you see. Still, the format for the AC_INIT macro as it exists now is obsolete, so I believe it's better to change to the current format. Changing AC_OUTPUT to the current style is also a good move IMHO. There's another change I'd also suggest - renaming configure.in to configure.ac, as autoconf now suggests the ".ac" extension. That can be done later. Art Haas ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-16 06:22 Message: Logged In: YES user_id=21627 It appears that you did not test this change. AC_INIT does not define VERSION, but PACKAGE_VERSION. Even if this is fixed (somehow), the resulting pyconfig.h will be installed, and then conflict in its PACKAGE_VERSION definition with other packages which also use autoconf. So I'm not sure this should be done at all. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=623771&group_id=5470 From noreply@sourceforge.net Wed Oct 16 17:50:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Oct 2002 09:50:50 -0700 Subject: [Patches] [ python-Patches-623780 ] configure.in obsolete macro replacement Message-ID: Patches item #623780, was opened at 2002-10-15 16:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=623780&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Art Haas (ahaas) Assigned to: Martin v. Löwis (loewis) Summary: configure.in obsolete macro replacement Initial Comment: Hi. Here's a patch that replaces the obsolete AC_STRUCT_ST_RDEV and AC_STRUCT_ST_BLKSIZE macros with their new counterparts from AC_CHECK_MEMBERS. In replacing these two macros, the pyconfig.h.in file had the deprecated definitions for these two macros removed as well as the deprecated form for the AC_STRUCT_ST_BLOCKS macro, and the associated changes to posixmodule.c to test for the new preprocessor definitions were added. While fiddling with pyconfig.h.in, I also removed the deprecated form for time zone macros, and made a change to the timemodule.c file so it will use the new preprocessor token. I've rebuilt my python with these changes and it looks alright. The line numbers for the configure.in patch may be a little off as I've modified it slightly by changing the AC_INIT macro - there is a patch submitted for that change as well. Art Haas ---------------------------------------------------------------------- >Comment By: Art Haas (ahaas) Date: 2002-10-16 11:50 Message: Logged In: YES user_id=629911 My docs are for autoconf-2.54 and the path for the info docs is ... Structures -> Particular Structures This page gives the summary for AC_STRUCT_ST_BLKSIZE and AC_STRUCT_ST_RDEV, and in the description of the two macros it lists them as obsolete and gives the replacement AC_CHECK_MEMBERS macro. I think it's a shortcoming in the autoconf documentation that the macro listing obsolete macros doesn't list the AC_CHECK_MEMBERS macro - it points to the AC_STRUCT_ST_BLKSIZE macro instead. I don't have the docs for autoconf-2.53 anymore to check if these changes were listed there as well. Art Haas ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-16 07:26 Message: Logged In: YES user_id=21627 Can you please point to the documentation that declares those macros as obsolete? I could only find that AC_ST_RDEV is obsolete, and replaced by AC_STRUCT_ST_RDEV. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=623780&group_id=5470 From noreply@sourceforge.net Wed Oct 16 20:32:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Oct 2002 12:32:05 -0700 Subject: [Patches] [ python-Patches-623771 ] autoconf-2.5X tweaks for configure.in Message-ID: Patches item #623771, was opened at 2002-10-15 23:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=623771&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Art Haas (ahaas) Assigned to: Martin v. Löwis (loewis) Summary: autoconf-2.5X tweaks for configure.in Initial Comment: Hi. Here's a small patch that adjust AC_INIT and AC_OUTPUT from the autoconf-2.13 style to the new autoconf-2.5X style. In changing these macros to their new format, the addition of AC_CONFIG_SRCDIR and AC_CONFIG_FILES is required. I've also removed the VERSION macro as that value can be defined in the second argument of AC_INIT. Art Haas ahaas@neosoft.com ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-16 21:32 Message: Logged In: YES user_id=21627 Can you please verify the setting of VERSION in your generate Makefile? When I use your patch, I get VERSION= whereas I should get VERSION= 2.3 Also, can you please use autoconf 2.53? This is the version that Python is currently is developed with, and we cannot make use of strategies or features that are available in 2.54 only. ---------------------------------------------------------------------- Comment By: Art Haas (ahaas) Date: 2002-10-16 18:44 Message: Logged In: YES user_id=629911 Hi. I did test this, and it worked fine - as far as I could tell. The autoconf docs I have (autoconf-2.54) show that AC_INIT is defined like ... AC_INIT (PACKAGE, VERSION, [BUG-REPORT], [TARNAME]) ... and PACKAGE_VERSION is taken from VERSION. I suppose that if there is a conflict, then the variable VERSION can be directly defined after AC_INIT, and it can be specified to whatever is needed to avoid the problems you see. Still, the format for the AC_INIT macro as it exists now is obsolete, so I believe it's better to change to the current format. Changing AC_OUTPUT to the current style is also a good move IMHO. There's another change I'd also suggest - renaming configure.in to configure.ac, as autoconf now suggests the ".ac" extension. That can be done later. Art Haas ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-16 13:22 Message: Logged In: YES user_id=21627 It appears that you did not test this change. AC_INIT does not define VERSION, but PACKAGE_VERSION. Even if this is fixed (somehow), the resulting pyconfig.h will be installed, and then conflict in its PACKAGE_VERSION definition with other packages which also use autoconf. So I'm not sure this should be done at all. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=623771&group_id=5470 From noreply@sourceforge.net Wed Oct 16 21:29:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Oct 2002 13:29:49 -0700 Subject: [Patches] [ python-Patches-623780 ] configure.in obsolete macro replacement Message-ID: Patches item #623780, was opened at 2002-10-15 23:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=623780&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Art Haas (ahaas) Assigned to: Martin v. Löwis (loewis) Summary: configure.in obsolete macro replacement Initial Comment: Hi. Here's a patch that replaces the obsolete AC_STRUCT_ST_RDEV and AC_STRUCT_ST_BLKSIZE macros with their new counterparts from AC_CHECK_MEMBERS. In replacing these two macros, the pyconfig.h.in file had the deprecated definitions for these two macros removed as well as the deprecated form for the AC_STRUCT_ST_BLOCKS macro, and the associated changes to posixmodule.c to test for the new preprocessor definitions were added. While fiddling with pyconfig.h.in, I also removed the deprecated form for time zone macros, and made a change to the timemodule.c file so it will use the new preprocessor token. I've rebuilt my python with these changes and it looks alright. The line numbers for the configure.in patch may be a little off as I've modified it slightly by changing the AC_INIT macro - there is a patch submitted for that change as well. Art Haas ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-16 22:29 Message: Logged In: YES user_id=21627 I see that in the 2.53 docs as well. Thanks for the patch, committed as configure 1.347 configure.in 1.358 pyconfig.h.in 1.55 posixmodule.c 2.269 timemodule.c 2.132 ---------------------------------------------------------------------- Comment By: Art Haas (ahaas) Date: 2002-10-16 18:50 Message: Logged In: YES user_id=629911 My docs are for autoconf-2.54 and the path for the info docs is ... Structures -> Particular Structures This page gives the summary for AC_STRUCT_ST_BLKSIZE and AC_STRUCT_ST_RDEV, and in the description of the two macros it lists them as obsolete and gives the replacement AC_CHECK_MEMBERS macro. I think it's a shortcoming in the autoconf documentation that the macro listing obsolete macros doesn't list the AC_CHECK_MEMBERS macro - it points to the AC_STRUCT_ST_BLKSIZE macro instead. I don't have the docs for autoconf-2.53 anymore to check if these changes were listed there as well. Art Haas ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-16 14:26 Message: Logged In: YES user_id=21627 Can you please point to the documentation that declares those macros as obsolete? I could only find that AC_ST_RDEV is obsolete, and replaced by AC_STRUCT_ST_RDEV. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=623780&group_id=5470 From noreply@sourceforge.net Wed Oct 16 22:59:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Oct 2002 14:59:16 -0700 Subject: [Patches] [ python-Patches-624325 ] attributes for urlsplit, urlparse result Message-ID: Patches item #624325, was opened at 2002-10-16 17:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=624325&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: attributes for urlsplit, urlparse result Initial Comment: This patch to Lib/urlparse.py makes the fields of the results accessible as named attributes from the result object. The result objects are still small since they derive from tuple and have no __dict__, though there's some additional cost in construction (a temporary tuple is created and passed to tuple.__new__). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=624325&group_id=5470 From noreply@sourceforge.net Thu Oct 17 16:55:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Oct 2002 08:55:44 -0700 Subject: [Patches] [ python-Patches-623771 ] autoconf-2.5X tweaks for configure.in Message-ID: Patches item #623771, was opened at 2002-10-15 16:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=623771&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Art Haas (ahaas) Assigned to: Martin v. Löwis (loewis) Summary: autoconf-2.5X tweaks for configure.in Initial Comment: Hi. Here's a small patch that adjust AC_INIT and AC_OUTPUT from the autoconf-2.13 style to the new autoconf-2.5X style. In changing these macros to their new format, the addition of AC_CONFIG_SRCDIR and AC_CONFIG_FILES is required. I've also removed the VERSION macro as that value can be defined in the second argument of AC_INIT. Art Haas ahaas@neosoft.com ---------------------------------------------------------------------- >Comment By: Art Haas (ahaas) Date: 2002-10-17 10:55 Message: Logged In: YES user_id=629911 My Makefile has a blank VERSION also, so I see that the part of the patch where I removed the VERSION variable is wrong. I'm attaching a new patch for the AC_INIT bits of configure.in. In this patch, there are a couple of variables defined using m4_define(), and these are then used to provide the version argument for AC_INIT and the value for the VERSION variable. After rebuilding configure with this patch, the variable VERSION in the Makefile is set to 2.3, as it should be. The AC_OUTPUT changes from the first patch are still good. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-16 14:32 Message: Logged In: YES user_id=21627 Can you please verify the setting of VERSION in your generate Makefile? When I use your patch, I get VERSION= whereas I should get VERSION= 2.3 Also, can you please use autoconf 2.53? This is the version that Python is currently is developed with, and we cannot make use of strategies or features that are available in 2.54 only. ---------------------------------------------------------------------- Comment By: Art Haas (ahaas) Date: 2002-10-16 11:44 Message: Logged In: YES user_id=629911 Hi. I did test this, and it worked fine - as far as I could tell. The autoconf docs I have (autoconf-2.54) show that AC_INIT is defined like ... AC_INIT (PACKAGE, VERSION, [BUG-REPORT], [TARNAME]) ... and PACKAGE_VERSION is taken from VERSION. I suppose that if there is a conflict, then the variable VERSION can be directly defined after AC_INIT, and it can be specified to whatever is needed to avoid the problems you see. Still, the format for the AC_INIT macro as it exists now is obsolete, so I believe it's better to change to the current format. Changing AC_OUTPUT to the current style is also a good move IMHO. There's another change I'd also suggest - renaming configure.in to configure.ac, as autoconf now suggests the ".ac" extension. That can be done later. Art Haas ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-16 06:22 Message: Logged In: YES user_id=21627 It appears that you did not test this change. AC_INIT does not define VERSION, but PACKAGE_VERSION. Even if this is fixed (somehow), the resulting pyconfig.h will be installed, and then conflict in its PACKAGE_VERSION definition with other packages which also use autoconf. So I'm not sure this should be done at all. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=623771&group_id=5470 From noreply@sourceforge.net Thu Oct 17 18:09:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Oct 2002 10:09:46 -0700 Subject: [Patches] [ python-Patches-624325 ] attributes for urlsplit, urlparse result Message-ID: Patches item #624325, was opened at 2002-10-16 17:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=624325&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) >Assigned to: Guido van Rossum (gvanrossum) Summary: attributes for urlsplit, urlparse result Initial Comment: This patch to Lib/urlparse.py makes the fields of the results accessible as named attributes from the result object. The result objects are still small since they derive from tuple and have no __dict__, though there's some additional cost in construction (a temporary tuple is created and passed to tuple.__new__). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-17 13:09 Message: Logged In: YES user_id=3066 New version of the patch. This adds a "url" attribute to each type of result, providing the result of urlunsplit() / urlunparse() for the components of the result object. Tests and documentation have been updated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=624325&group_id=5470 From noreply@sourceforge.net Thu Oct 17 21:03:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Oct 2002 13:03:07 -0700 Subject: [Patches] [ python-Patches-624325 ] attributes for urlsplit, urlparse result Message-ID: Patches item #624325, was opened at 2002-10-16 17:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=624325&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Guido van Rossum (gvanrossum) Summary: attributes for urlsplit, urlparse result Initial Comment: This patch to Lib/urlparse.py makes the fields of the results accessible as named attributes from the result object. The result objects are still small since they derive from tuple and have no __dict__, though there's some additional cost in construction (a temporary tuple is created and passed to tuple.__new__). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-17 16:03 Message: Logged In: YES user_id=3066 Based on comments from Guido, provide a geturl() method instead of the url property, since it actually does more work than just retrieving data. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-17 13:09 Message: Logged In: YES user_id=3066 New version of the patch. This adds a "url" attribute to each type of result, providing the result of urlunsplit() / urlunparse() for the components of the result object. Tests and documentation have been updated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=624325&group_id=5470 From noreply@sourceforge.net Thu Oct 17 23:19:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Oct 2002 15:19:40 -0700 Subject: [Patches] [ python-Patches-613173 ] koi8_u codec Message-ID: Patches item #613173, was opened at 2002-09-23 08:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613173&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Maxim Dzumanenko (mdzumanenko) Assigned to: Neal Norwitz (nnorwitz) Summary: koi8_u codec Initial Comment: This patch adds koi8_u codec ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-17 18:19 Message: Logged In: YES user_id=33168 Thanks, Maxim and MAL! Checked in as: Lib/encodings/koi8_u.py 1.1 and 1.1.2.1 Misc/ACKS 1.211 and 1.149.4.13 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-12 08:10 Message: Logged In: YES user_id=38388 About the backport: new codecs can generally always be backported. Please check the code into 2.3 and 2.2.2. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-12 08:08 Message: Logged In: YES user_id=38388 Here's a new version of the codec which fixes some encoding bugs and uses the approach of inheriting KOI8R as suggested by the RFC. Also changed the copyright to the PSF. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-11 19:05 Message: Logged In: YES user_id=33168 I've updated the patch for whitespace normalization and made hex chars a-f instead of A-F. It is easy to do a diff between koi8_[ru].py now. I have no idea if the encoding is correct. If someone can verify it is correct, assign back to me for checkin. Also, should this be backported if accepted? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613173&group_id=5470 From noreply@sourceforge.net Sat Oct 19 06:20:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Oct 2002 22:20:57 -0700 Subject: [Patches] [ python-Patches-625513 ] sets.BaseSet.isdisjointset(other) Message-ID: Patches item #625513, was opened at 2002-10-18 23:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=625513&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Shane Holloway (shane_holloway) Assigned to: Nobody/Anonymous (nobody) Summary: sets.BaseSet.isdisjointset(other) Initial Comment: Provides an optimized test for disjoint sets without creating an intersection, and returning after finding first shared element. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=625513&group_id=5470 From noreply@sourceforge.net Sat Oct 19 07:33:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Oct 2002 23:33:51 -0700 Subject: [Patches] [ python-Patches-625513 ] sets.BaseSet.isdisjointset(other) Message-ID: Patches item #625513, was opened at 2002-10-19 01:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=625513&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Shane Holloway (shane_holloway) Assigned to: Nobody/Anonymous (nobody) Summary: sets.BaseSet.isdisjointset(other) Initial Comment: Provides an optimized test for disjoint sets without creating an intersection, and returning after finding first shared element. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-10-19 02:33 Message: Logged In: YES user_id=31435 In what sense is this optimized? People usually mean "speed" when they use that word without qualification, but this surely runs much slower (most of the time) if the sets are in fact disjoint. OTOH, I'm sure it does run much faster (most of the time) if the sets have the same elements. If a method is merely provided for speed in *some* cases, it's generally a hard sell. It would help your case if the docs here spelled out exactly when and why someone would want to use the new method; else it appears mysteriously redundant. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=625513&group_id=5470 From noreply@sourceforge.net Sun Oct 20 13:54:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Oct 2002 05:54:44 -0700 Subject: [Patches] [ python-Patches-624180 ] HTTP Auth support for xmlrpclib Message-ID: Patches item #624180, was opened at 2002-10-16 18:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=624180&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Phillip J. Eby (pje) >Assigned to: Fredrik Lundh (effbot) Summary: HTTP Auth support for xmlrpclib Initial Comment: This patch adds code and docs to support the use of HTTP/HTTPS "Basic Authorization" with xmlrpclib. It does this using the "http://user:pass@host:port/" syntax, based on existing code in urllib and xmlrpclib. I have tested the code change with and without basic auth on my own servers, but do not know how I could create a reasonable addition to the test suite, since a server connection would be required. My patch includes a patch to Doc/lib/libxmlrpclib.tex, but I'm not sure if I added the text in the best place. It may be that it should be a note in the 'seealso' section on that page instead, but I wasn't sure if that was correct style for the library documentation. For the code patch, I tried to match the style of the surrounding code as closely as possible, including the style used for code comments. The patch is against current (as of this moment) Python CVS. Please let me know if there's any other info you need or anything that I should change for this. Thanks. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2002-10-20 14:54 Message: Logged In: YES user_id=38376 looks good to me. thanks /F ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=624180&group_id=5470 From noreply@sourceforge.net Sun Oct 20 20:22:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Oct 2002 12:22:13 -0700 Subject: [Patches] [ python-Patches-535335 ] 2.2 patches for BSD/OS 5.0 Message-ID: Patches item #535335, was opened at 2002-03-26 19:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=535335&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: Rejected Priority: 5 Submitted By: Jeffrey Honig (jchonig) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2 patches for BSD/OS 5.0 Initial Comment: The following patches were necessary to get Python 2.2 to work on BSD/OS 5.0. More may follow as we are still attempting to resolve some issues related to the regression tests (although these may be OS issues). Thanks. Jeff ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-20 21:22 Message: Logged In: YES user_id=21627 I'm unsure what to do with these patches? Are they exclusively for 2.2? It seems it would be better to apply them exclusively for 2.3... ---------------------------------------------------------------------- Comment By: Jeffrey Honig (jchonig) Date: 2002-10-15 14:57 Message: Logged In: YES user_id=96862 Sorry about my lack of response. Work is busy. Just ignore the changes to regrtest.py and the rest of the changes are fine. We'll report more next time we have a chance to run the regression tests. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 23:19 Message: Logged In: YES user_id=21627 Rejecting the patch because of inactivity. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-23 05:22 Message: Logged In: YES user_id=33168 Jeff, any chances of getting updates for this patch? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 10:49 Message: Logged In: YES user_id=21627 Is an update of this patch forthcoming? ---------------------------------------------------------------------- Comment By: Jeffrey Honig (jchonig) Date: 2002-03-26 20:08 Message: Logged In: YES user_id=96862 Re: configure.in vs configure: we don't use autoconf here so modifying configure.in doesn't help us. I should have copies the changes and submitted them, but then they aren't too hard to figure out.... Re: contrib{lib/include}: We install many of the packages that we install from the net (which we call contrib packages) into the /usr/contrib heirarchy. They won't be found by setup.py unless those paths are present. Re: regrtest.py: Apologies about the regrtest.py content, there are some tests in there that shouldn't be, ignore it for now, I'll submit an update later. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-03-26 19:53 Message: Logged In: YES user_id=33168 Lib/posixfile.py & Lib/test/test_fcntl.py seem harmless. configure is generated, so configure.in will need the changes made to it. There seem to be many tests which fail, but perhaps shouldn't: fork1, locale, minidom, poll, pyexpat, sax, unicode_file? I'm also unsure of the benefit of adding contrib/{lib/include} to setup.py. This could be fine, but I don't know anything about distutils. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=535335&group_id=5470 From noreply@sourceforge.net Sun Oct 20 22:12:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Oct 2002 14:12:27 -0700 Subject: [Patches] [ python-Patches-562501 ] Add isxxx() methods to string objects Message-ID: Patches item #562501, was opened at 2002-05-30 13:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=562501&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Raymond Hettinger (rhettinger) Summary: Add isxxx() methods to string objects Initial Comment: Here's the patch for the isxxx methods. If it's up to spec, let me know and I'll add documentation and expand the unittests. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-20 16:12 Message: Logged In: YES user_id=80475 This one is taking a while because I'm not entirely clear on the inclusion/exclusion criteria for classifying Unicode characters for the various isxxx methods. I'm spending some time with the big Unicode 3.0 book and will post a patch when I know how to proceed. If any one already has a clear sense of direction, I'm all ears. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 16:46 Message: Logged In: YES user_id=21627 Raymond, any news on this? I like the idea. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-06-30 14:58 Message: Logged In: YES user_id=80475 Unassigning this because I'm away for five weeks. The equivalent Unicode operations are not as clearly defined as they are for Ascii. Was researching what is done in other programming languages. Also, there was a py-dev discussion that suggested that the function names be changed to something more clear than their names in C. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-30 13:41 Message: Logged In: YES user_id=6380 Thanks! But what about adding the same methods to Unicode objects? I think that's the point of using methods -- supporting the same operations for both string types. Also, Paul Prescod wanted ishexdigit instead of isxdigit. Not sure if I agree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=562501&group_id=5470 From noreply@sourceforge.net Sun Oct 20 23:03:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Oct 2002 15:03:54 -0700 Subject: [Patches] [ python-Patches-626105 ] Take advantage of string.center Message-ID: Patches item #626105, was opened at 2002-10-20 17:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626105&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 4 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Take advantage of string.center Initial Comment: Replaces the _center function in the calendar module with the center method for strings. For situations with uneven padding, the behavior is slightly different in that the center method puts the extra space on the right instead of the left: >>> 'the'.center(6) ' the ' >>> calendar._center('the', 6) ' the ' Gives minor improvements in speed, readability, code size, and tutorial value. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626105&group_id=5470 From noreply@sourceforge.net Sun Oct 20 23:20:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Oct 2002 15:20:21 -0700 Subject: [Patches] [ python-Patches-562501 ] Add isxxx() methods to string objects Message-ID: Patches item #562501, was opened at 2002-05-30 18:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=562501&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Add isxxx() methods to string objects Initial Comment: Here's the patch for the isxxx methods. If it's up to spec, let me know and I'll add documentation and expand the unittests. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-20 22:20 Message: Logged In: YES user_id=38388 I'd suggest to start with the standard ASCII characters for the methods you are suggesting to add and then complete the sets using the various categories listed on http://www.unicode.org/Public/UNIDATA/UnicodeData.html e.g. punctation (P*) is a general category in the Unicode database, control too (Cc). Visibility and printability depend on available fonts, so I'm not sure what to do about these. Hex chars are the same as for 8-bit strings. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-20 21:12 Message: Logged In: YES user_id=80475 This one is taking a while because I'm not entirely clear on the inclusion/exclusion criteria for classifying Unicode characters for the various isxxx methods. I'm spending some time with the big Unicode 3.0 book and will post a patch when I know how to proceed. If any one already has a clear sense of direction, I'm all ears. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 21:46 Message: Logged In: YES user_id=21627 Raymond, any news on this? I like the idea. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-06-30 19:58 Message: Logged In: YES user_id=80475 Unassigning this because I'm away for five weeks. The equivalent Unicode operations are not as clearly defined as they are for Ascii. Was researching what is done in other programming languages. Also, there was a py-dev discussion that suggested that the function names be changed to something more clear than their names in C. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-30 18:41 Message: Logged In: YES user_id=6380 Thanks! But what about adding the same methods to Unicode objects? I think that's the point of using methods -- supporting the same operations for both string types. Also, Paul Prescod wanted ishexdigit instead of isxdigit. Not sure if I agree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=562501&group_id=5470 From noreply@sourceforge.net Mon Oct 21 20:02:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Oct 2002 12:02:28 -0700 Subject: [Patches] [ python-Patches-626485 ] Support Unicode normalization Message-ID: Patches item #626485, was opened at 2002-10-21 21:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626485&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Support Unicode normalization Initial Comment: This patch adds support for the normalization forms NFC, NFKC, NFD, NFKD. It passes the NormalizationTest-3.2.0.txt tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626485&group_id=5470 From noreply@sourceforge.net Mon Oct 21 20:08:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Oct 2002 12:08:14 -0700 Subject: [Patches] [ python-Patches-626105 ] Take advantage of string.center Message-ID: Patches item #626105, was opened at 2002-10-21 00:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626105&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 4 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Raymond Hettinger (rhettinger) Summary: Take advantage of string.center Initial Comment: Replaces the _center function in the calendar module with the center method for strings. For situations with uneven padding, the behavior is slightly different in that the center method puts the extra space on the right instead of the left: >>> 'the'.center(6) ' the ' >>> calendar._center('the', 6) ' the ' Gives minor improvements in speed, readability, code size, and tutorial value. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-21 21:08 Message: Logged In: YES user_id=21627 The patch looks fine, please apply it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626105&group_id=5470 From noreply@sourceforge.net Mon Oct 21 22:11:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Oct 2002 14:11:38 -0700 Subject: [Patches] [ python-Patches-626548 ] Support Hangul Syllable names Message-ID: Patches item #626548, was opened at 2002-10-21 23:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626548&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Support Hangul Syllable names Initial Comment: This patch implements section 25.2 of ISO 10646 (Character names and annotations for Hangul syllables). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626548&group_id=5470 From noreply@sourceforge.net Mon Oct 21 22:14:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Oct 2002 14:14:07 -0700 Subject: [Patches] [ python-Patches-590377 ] db4 include not found Message-ID: Patches item #590377, was opened at 2002-08-02 21:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470 Category: Build Group: Python 2.3 >Status: Open >Resolution: Invalid Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: db4 include not found Initial Comment: setup.py looks for the db4 library in /usr/lib, but doesn't look for the header in /usr/include (as you find it on Debian unstable) ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2002-10-21 21:14 Message: Logged In: YES user_id=60903 Martin, you're closing reports very quickly ;-) What makes you think the problem is solved? The code doesn't search /usr/include for db.h. Updated patch included. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 13:06 Message: Logged In: YES user_id=21627 The patch is out-of-date, and appears to be unnecessary. I'm rejecting it - if you still think something needs to be done, please submit a new patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470 From noreply@sourceforge.net Mon Oct 21 22:42:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Oct 2002 14:42:03 -0700 Subject: [Patches] [ python-Patches-590377 ] db4 include not found Message-ID: Patches item #590377, was opened at 2002-08-02 23:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: Invalid Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: db4 include not found Initial Comment: setup.py looks for the db4 library in /usr/lib, but doesn't look for the header in /usr/include (as you find it on Debian unstable) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-21 23:42 Message: Logged In: YES user_id=21627 Ok, I admit that the patch might be needed; I think it is quite incorrect, though: - Doesn't it cause -I/usr/include be added to the compilation statement? - Why is that done for db4 and not db3? - How can we know what bsddb version /usr/include/db.h belongs to? Guessing that it is db4 is error-prone, so it might be, in fact, better not to find that file. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-21 23:14 Message: Logged In: YES user_id=60903 Martin, you're closing reports very quickly ;-) What makes you think the problem is solved? The code doesn't search /usr/include for db.h. Updated patch included. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 15:06 Message: Logged In: YES user_id=21627 The patch is out-of-date, and appears to be unnecessary. I'm rejecting it - if you still think something needs to be done, please submit a new patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470 From noreply@sourceforge.net Mon Oct 21 22:54:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Oct 2002 14:54:54 -0700 Subject: [Patches] [ python-Patches-590377 ] db4 include not found Message-ID: Patches item #590377, was opened at 2002-08-02 21:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: Invalid Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: db4 include not found Initial Comment: setup.py looks for the db4 library in /usr/lib, but doesn't look for the header in /usr/include (as you find it on Debian unstable) ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2002-10-21 21:54 Message: Logged In: YES user_id=60903 > - Doesn't it cause -I/usr/include be added to the > compilation statement? yes, that's not correct > - Why is that done for db4 and not db3? On Debian only one libdb-dev package can be installed at build time. I assure with the build dependencies that I get the correct one. > - How can we know what bsddb version /usr/include/db.h > belongs to? Guessing that it is db4 is error-prone, so it > might be, in fact, better not to find that file. maybe grep for DB_VERSION_MAJOR in the file? I admit, this issue should be a bug report, not a patch ... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-21 21:42 Message: Logged In: YES user_id=21627 Ok, I admit that the patch might be needed; I think it is quite incorrect, though: - Doesn't it cause -I/usr/include be added to the compilation statement? - Why is that done for db4 and not db3? - How can we know what bsddb version /usr/include/db.h belongs to? Guessing that it is db4 is error-prone, so it might be, in fact, better not to find that file. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-21 21:14 Message: Logged In: YES user_id=60903 Martin, you're closing reports very quickly ;-) What makes you think the problem is solved? The code doesn't search /usr/include for db.h. Updated patch included. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 13:06 Message: Logged In: YES user_id=21627 The patch is out-of-date, and appears to be unnecessary. I'm rejecting it - if you still think something needs to be done, please submit a new patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470 From noreply@sourceforge.net Mon Oct 21 23:11:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Oct 2002 15:11:52 -0700 Subject: [Patches] [ python-Patches-590377 ] db4 include not found Message-ID: Patches item #590377, was opened at 2002-08-02 23:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: Invalid Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: db4 include not found Initial Comment: setup.py looks for the db4 library in /usr/lib, but doesn't look for the header in /usr/include (as you find it on Debian unstable) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-22 00:11 Message: Logged In: YES user_id=21627 As a bug report, I would close this as "Won't fix", pointing you to the option of not using setup.py, but compiling the module through Modules/Setup. I'd prefer to get a patch, but that should be one that works on all systems. This one breaks on systems where /usr/include/db.h is not a bsddb 4 header file. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-21 23:54 Message: Logged In: YES user_id=60903 > - Doesn't it cause -I/usr/include be added to the > compilation statement? yes, that's not correct > - Why is that done for db4 and not db3? On Debian only one libdb-dev package can be installed at build time. I assure with the build dependencies that I get the correct one. > - How can we know what bsddb version /usr/include/db.h > belongs to? Guessing that it is db4 is error-prone, so it > might be, in fact, better not to find that file. maybe grep for DB_VERSION_MAJOR in the file? I admit, this issue should be a bug report, not a patch ... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-21 23:42 Message: Logged In: YES user_id=21627 Ok, I admit that the patch might be needed; I think it is quite incorrect, though: - Doesn't it cause -I/usr/include be added to the compilation statement? - Why is that done for db4 and not db3? - How can we know what bsddb version /usr/include/db.h belongs to? Guessing that it is db4 is error-prone, so it might be, in fact, better not to find that file. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-21 23:14 Message: Logged In: YES user_id=60903 Martin, you're closing reports very quickly ;-) What makes you think the problem is solved? The code doesn't search /usr/include for db.h. Updated patch included. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 15:06 Message: Logged In: YES user_id=21627 The patch is out-of-date, and appears to be unnecessary. I'm rejecting it - if you still think something needs to be done, please submit a new patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470 From noreply@sourceforge.net Tue Oct 22 06:17:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Oct 2002 22:17:22 -0700 Subject: [Patches] [ python-Patches-626105 ] Take advantage of string.center Message-ID: Patches item #626105, was opened at 2002-10-20 17:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626105&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 4 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Take advantage of string.center Initial Comment: Replaces the _center function in the calendar module with the center method for strings. For situations with uneven padding, the behavior is slightly different in that the center method puts the extra space on the right instead of the left: >>> 'the'.center(6) ' the ' >>> calendar._center('the', 6) ' the ' Gives minor improvements in speed, readability, code size, and tutorial value. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-22 00:17 Message: Logged In: YES user_id=80475 Done. See calendar.py 1.30. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-21 14:08 Message: Logged In: YES user_id=21627 The patch looks fine, please apply it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626105&group_id=5470 From noreply@sourceforge.net Tue Oct 22 06:54:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Oct 2002 22:54:04 -0700 Subject: [Patches] [ python-Patches-625513 ] sets.BaseSet.isdisjointset(other) Message-ID: Patches item #625513, was opened at 2002-10-19 00:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=625513&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Shane Holloway (shane_holloway) Assigned to: Nobody/Anonymous (nobody) Summary: sets.BaseSet.isdisjointset(other) Initial Comment: Provides an optimized test for disjoint sets without creating an intersection, and returning after finding first shared element. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-22 00:54 Message: Logged In: YES user_id=80475 In general, I'm a fan of early-out routines, but I agree with Tim, unless this patch solves a compelling common case and is clear about when and whether it can be used to advantage, the filter based itersection method remains the best solution for the general case. Unless a compelling, common use case can be shown, I recommend that we don't fatten the interface further. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-10-19 01:33 Message: Logged In: YES user_id=31435 In what sense is this optimized? People usually mean "speed" when they use that word without qualification, but this surely runs much slower (most of the time) if the sets are in fact disjoint. OTOH, I'm sure it does run much faster (most of the time) if the sets have the same elements. If a method is merely provided for speed in *some* cases, it's generally a hard sell. It would help your case if the docs here spelled out exactly when and why someone would want to use the new method; else it appears mysteriously redundant. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=625513&group_id=5470 From noreply@sourceforge.net Tue Oct 22 19:21:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Oct 2002 11:21:32 -0700 Subject: [Patches] [ python-Patches-624180 ] HTTP Auth support for xmlrpclib Message-ID: Patches item #624180, was opened at 2002-10-16 18:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=624180&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Phillip J. Eby (pje) Assigned to: Fredrik Lundh (effbot) Summary: HTTP Auth support for xmlrpclib Initial Comment: This patch adds code and docs to support the use of HTTP/HTTPS "Basic Authorization" with xmlrpclib. It does this using the "http://user:pass@host:port/" syntax, based on existing code in urllib and xmlrpclib. I have tested the code change with and without basic auth on my own servers, but do not know how I could create a reasonable addition to the test suite, since a server connection would be required. My patch includes a patch to Doc/lib/libxmlrpclib.tex, but I'm not sure if I added the text in the best place. It may be that it should be a note in the 'seealso' section on that page instead, but I wasn't sure if that was correct style for the library documentation. For the code patch, I tried to match the style of the surrounding code as closely as possible, including the style used for code comments. The patch is against current (as of this moment) Python CVS. Please let me know if there's any other info you need or anything that I should change for this. Thanks. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2002-10-20 14:54 Message: Logged In: YES user_id=38376 looks good to me. thanks /F ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=624180&group_id=5470 From noreply@sourceforge.net Tue Oct 22 19:32:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Oct 2002 11:32:58 -0700 Subject: [Patches] [ python-Patches-625513 ] sets.BaseSet.isdisjointset(other) Message-ID: Patches item #625513, was opened at 2002-10-18 23:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=625513&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Shane Holloway (shane_holloway) Assigned to: Nobody/Anonymous (nobody) Summary: sets.BaseSet.isdisjointset(other) Initial Comment: Provides an optimized test for disjoint sets without creating an intersection, and returning after finding first shared element. ---------------------------------------------------------------------- >Comment By: Shane Holloway (shane_holloway) Date: 2002-10-22 12:32 Message: Logged In: YES user_id=283742 I definitely agree that this disjoint set test and an intersection both have linear time complexity, but the intersection also has a memory complexity that a disjoint test does not have. Secondly, in the case of an intersecting set, it short-circuts the rest of the loop since it already has the answer, halving the time complexity on average. However, disjoint test doesn't benefit from the C-loop of filter that the intersection does. When I wrote this patch, I was creating some large sets doing reachability searches, and I wanted to merge the intersecting ones. I started by examining the length of the intersection, but the time to allocate the complete result was bottlenecking things. (400K entries.) Thus I wrote the disjoint test and things went much faster. But, as you said, this is neither common nor compelling. So I assumed it was a common enough function that others would profit from having it the standard library. It was certainly all over my set theory classes a few years ago. ;) Perhaps what we need is more c-loop functions to add to map, filter and reduce? A function called 'first' would work wonders here and other places. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-21 23:54 Message: Logged In: YES user_id=80475 In general, I'm a fan of early-out routines, but I agree with Tim, unless this patch solves a compelling common case and is clear about when and whether it can be used to advantage, the filter based itersection method remains the best solution for the general case. Unless a compelling, common use case can be shown, I recommend that we don't fatten the interface further. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-10-19 00:33 Message: Logged In: YES user_id=31435 In what sense is this optimized? People usually mean "speed" when they use that word without qualification, but this surely runs much slower (most of the time) if the sets are in fact disjoint. OTOH, I'm sure it does run much faster (most of the time) if the sets have the same elements. If a method is merely provided for speed in *some* cases, it's generally a hard sell. It would help your case if the docs here spelled out exactly when and why someone would want to use the new method; else it appears mysteriously redundant. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=625513&group_id=5470 From noreply@sourceforge.net Tue Oct 22 22:02:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Oct 2002 14:02:53 -0700 Subject: [Patches] [ python-Patches-627105 ] warn about portability issue Message-ID: Patches item #627105, was opened at 2002-10-22 21:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=627105&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: warn about portability issue Initial Comment: It's conceivable that there is a platform with memory-protected pages smaller than 4 KB, and in that case if someone called PyObject_Free(p), where p pointed to an address towards the beginning of a page, the interpreter might incur a segment fault. This patch fixes the in-line docs so that it no longer incorrectly asserts that "It doesn't matter if this value is different from the native page size.". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=627105&group_id=5470 From noreply@sourceforge.net Wed Oct 23 11:27:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Oct 2002 03:27:16 -0700 Subject: [Patches] [ python-Patches-626485 ] Support Unicode normalization Message-ID: Patches item #626485, was opened at 2002-10-21 19:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626485&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Support Unicode normalization Initial Comment: This patch adds support for the normalization forms NFC, NFKC, NFD, NFKD. It passes the NormalizationTest-3.2.0.txt tests. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-23 10:27 Message: Logged In: YES user_id=38388 The patch looks Ok except for a few nits: * I'd rather like a single API normalize(form) which takes the form as string argument instead of NFKD, etc. * __getrecord should be renamed to _getrecord_ex; perhaps both should use a different name altogether, e.g. getunicoderecord * I think you have to add some #ifdef Py_UNICODE_WIDE in the code to avoid compiler warnings for narrow builds about non-const if expressions being always true due to size limits. * The filenames you are using should not include the '-Latest' suffix. If you download the files from unicode.org via FTP they don't have this extension. * The skip test message should include a reference of where to get the test file from, ie. ftp://ftp.unicode.org/Public/UNIDATA/NormalizationTest.txt Thanks for working on this ! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626485&group_id=5470 From noreply@sourceforge.net Wed Oct 23 11:32:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Oct 2002 03:32:44 -0700 Subject: [Patches] [ python-Patches-626548 ] Support Hangul Syllable names Message-ID: Patches item #626548, was opened at 2002-10-21 21:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626548&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Support Hangul Syllable names Initial Comment: This patch implements section 25.2 of ISO 10646 (Character names and annotations for Hangul syllables). ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-23 10:32 Message: Logged In: YES user_id=38388 One more minor nit: the indentation in the C file is 4 chars, please reindent your code accordingly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626548&group_id=5470 From noreply@sourceforge.net Wed Oct 23 11:36:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Oct 2002 03:36:43 -0700 Subject: [Patches] [ python-Patches-626485 ] Support Unicode normalization Message-ID: Patches item #626485, was opened at 2002-10-21 19:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626485&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Support Unicode normalization Initial Comment: This patch adds support for the normalization forms NFC, NFKC, NFD, NFKD. It passes the NormalizationTest-3.2.0.txt tests. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-23 10:36 Message: Logged In: YES user_id=38388 One more minor nit: the indentation in the C file is 4 chars, please reindent your code accordingly ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-23 10:27 Message: Logged In: YES user_id=38388 The patch looks Ok except for a few nits: * I'd rather like a single API normalize(form) which takes the form as string argument instead of NFKD, etc. * __getrecord should be renamed to _getrecord_ex; perhaps both should use a different name altogether, e.g. getunicoderecord * I think you have to add some #ifdef Py_UNICODE_WIDE in the code to avoid compiler warnings for narrow builds about non-const if expressions being always true due to size limits. * The filenames you are using should not include the '-Latest' suffix. If you download the files from unicode.org via FTP they don't have this extension. * The skip test message should include a reference of where to get the test file from, ie. ftp://ftp.unicode.org/Public/UNIDATA/NormalizationTest.txt Thanks for working on this ! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626485&group_id=5470 From noreply@sourceforge.net Wed Oct 23 11:42:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Oct 2002 03:42:03 -0700 Subject: [Patches] [ python-Patches-626548 ] Support Hangul Syllable names Message-ID: Patches item #626548, was opened at 2002-10-21 23:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626548&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Support Hangul Syllable names Initial Comment: This patch implements section 25.2 of ISO 10646 (Character names and annotations for Hangul syllables). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-23 12:42 Message: Logged In: YES user_id=21627 Perhaps the entire file should be formatted to conform with PEP 7 (single-tab indents, where a tab is worth 8 spaces). Should I submit a separate patch for this reformatting? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-23 12:32 Message: Logged In: YES user_id=38388 One more minor nit: the indentation in the C file is 4 chars, please reindent your code accordingly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626548&group_id=5470 From noreply@sourceforge.net Wed Oct 23 12:00:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Oct 2002 04:00:19 -0700 Subject: [Patches] [ python-Patches-626548 ] Support Hangul Syllable names Message-ID: Patches item #626548, was opened at 2002-10-21 21:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626548&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Support Hangul Syllable names Initial Comment: This patch implements section 25.2 of ISO 10646 (Character names and annotations for Hangul syllables). ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-23 11:00 Message: Logged In: YES user_id=38388 No, I'd rather leave things as they are w/r to indentation. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-23 10:42 Message: Logged In: YES user_id=21627 Perhaps the entire file should be formatted to conform with PEP 7 (single-tab indents, where a tab is worth 8 spaces). Should I submit a separate patch for this reformatting? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-23 10:32 Message: Logged In: YES user_id=38388 One more minor nit: the indentation in the C file is 4 chars, please reindent your code accordingly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626548&group_id=5470 From noreply@sourceforge.net Wed Oct 23 12:02:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Oct 2002 04:02:04 -0700 Subject: [Patches] [ python-Patches-626548 ] Support Hangul Syllable names Message-ID: Patches item #626548, was opened at 2002-10-21 21:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626548&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Support Hangul Syllable names Initial Comment: This patch implements section 25.2 of ISO 10646 (Character names and annotations for Hangul syllables). ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-23 11:02 Message: Logged In: YES user_id=38388 Apart from that the patch looks ok. Do you have some docs to go with it ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-23 11:00 Message: Logged In: YES user_id=38388 No, I'd rather leave things as they are w/r to indentation. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-23 10:42 Message: Logged In: YES user_id=21627 Perhaps the entire file should be formatted to conform with PEP 7 (single-tab indents, where a tab is worth 8 spaces). Should I submit a separate patch for this reformatting? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-23 10:32 Message: Logged In: YES user_id=38388 One more minor nit: the indentation in the C file is 4 chars, please reindent your code accordingly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626548&group_id=5470 From noreply@sourceforge.net Wed Oct 23 12:31:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Oct 2002 04:31:26 -0700 Subject: [Patches] [ python-Patches-626548 ] Support Hangul Syllable names Message-ID: Patches item #626548, was opened at 2002-10-21 23:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626548&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Support Hangul Syllable names Initial Comment: This patch implements section 25.2 of ISO 10646 (Character names and annotations for Hangul syllables). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-23 13:31 Message: Logged In: YES user_id=21627 Can you please elaborate this position? Is it not important to follow the established and agreed style guide? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-23 13:02 Message: Logged In: YES user_id=38388 Apart from that the patch looks ok. Do you have some docs to go with it ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-23 13:00 Message: Logged In: YES user_id=38388 No, I'd rather leave things as they are w/r to indentation. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-23 12:42 Message: Logged In: YES user_id=21627 Perhaps the entire file should be formatted to conform with PEP 7 (single-tab indents, where a tab is worth 8 spaces). Should I submit a separate patch for this reformatting? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-23 12:32 Message: Logged In: YES user_id=38388 One more minor nit: the indentation in the C file is 4 chars, please reindent your code accordingly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626548&group_id=5470 From noreply@sourceforge.net Wed Oct 23 12:41:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Oct 2002 04:41:07 -0700 Subject: [Patches] [ python-Patches-626548 ] Support Hangul Syllable names Message-ID: Patches item #626548, was opened at 2002-10-21 23:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626548&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Support Hangul Syllable names Initial Comment: This patch implements section 25.2 of ISO 10646 (Character names and annotations for Hangul syllables). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-23 13:41 Message: Logged In: YES user_id=21627 As for docs: I'd add a NEWS entry only. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-23 13:31 Message: Logged In: YES user_id=21627 Can you please elaborate this position? Is it not important to follow the established and agreed style guide? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-23 13:02 Message: Logged In: YES user_id=38388 Apart from that the patch looks ok. Do you have some docs to go with it ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-23 13:00 Message: Logged In: YES user_id=38388 No, I'd rather leave things as they are w/r to indentation. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-23 12:42 Message: Logged In: YES user_id=21627 Perhaps the entire file should be formatted to conform with PEP 7 (single-tab indents, where a tab is worth 8 spaces). Should I submit a separate patch for this reformatting? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-23 12:32 Message: Logged In: YES user_id=38388 One more minor nit: the indentation in the C file is 4 chars, please reindent your code accordingly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626548&group_id=5470 From noreply@sourceforge.net Wed Oct 23 18:23:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Oct 2002 10:23:24 -0700 Subject: [Patches] [ python-Patches-624180 ] HTTP Auth support for xmlrpclib Message-ID: Patches item #624180, was opened at 2002-10-16 16:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=624180&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Open Resolution: Fixed Priority: 5 Submitted By: Phillip J. Eby (pje) Assigned to: Fredrik Lundh (effbot) Summary: HTTP Auth support for xmlrpclib Initial Comment: This patch adds code and docs to support the use of HTTP/HTTPS "Basic Authorization" with xmlrpclib. It does this using the "http://user:pass@host:port/" syntax, based on existing code in urllib and xmlrpclib. I have tested the code change with and without basic auth on my own servers, but do not know how I could create a reasonable addition to the test suite, since a server connection would be required. My patch includes a patch to Doc/lib/libxmlrpclib.tex, but I'm not sure if I added the text in the best place. It may be that it should be a note in the 'seealso' section on that page instead, but I wasn't sure if that was correct style for the library documentation. For the code patch, I tried to match the style of the surrounding code as closely as possible, including the style used for code comments. The patch is against current (as of this moment) Python CVS. Please let me know if there's any other info you need or anything that I should change for this. Thanks. ---------------------------------------------------------------------- >Comment By: Phillip J. Eby (pje) Date: 2002-10-23 17:23 Message: Logged In: YES user_id=56214 Oops... There's a (very small) bug in both my and your versions of the patch. I forgot to do 'urllib.unquote(auth)' before doing the base64 encode. This means that if 'user' is an e-mail address or contains a colon, or 'password' contains an '@' sign, there's no way to get them into the auth string. adding: auth = urllib.unquote(auth) before the 'auth = base64.encodestring(auth)' statement does the trick. Thus, a 'user' of "pje@telecommunity.com" can be encoded in the URL as "pje%40telecommunity.com", which is awkward but usable. I discovered this when trying to port a script from Perl's RPC::XML, which supports this syntax, escapes included. Thanks! ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2002-10-20 12:54 Message: Logged In: YES user_id=38376 looks good to me. thanks /F ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=624180&group_id=5470 From noreply@sourceforge.net Thu Oct 24 10:36:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Oct 2002 02:36:58 -0700 Subject: [Patches] [ python-Patches-627900 ] Bytecode copy bug in freeze Message-ID: Patches item #627900, was opened at 2002-10-24 11:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=627900&group_id=5470 Category: Demos and tools Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Troels Walsted Hansen (troels) Assigned to: Nobody/Anonymous (nobody) Summary: Bytecode copy bug in freeze Initial Comment: modulefinder.py in Tools/freeze fails to copy co.co_freevars and co.co_cellvars, causing mysterious crashes when the -r (replace path) option is used with freeze. Debugging credit goes to Alexander Wilkens . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=627900&group_id=5470 From noreply@sourceforge.net Thu Oct 24 20:50:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Oct 2002 12:50:00 -0700 Subject: [Patches] [ python-Patches-628208 ] xmlrpclib: Optional 'nil' support Message-ID: Patches item #628208, was opened at 2002-10-24 21:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=628208&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Fredrik Lundh (effbot) Summary: xmlrpclib: Optional 'nil' support Initial Comment: This patch doesn't include documentation or test suite updates yet, and only touches the < The extension is defined at http://ontosys.com/xml-rpc/extensions.html. Outstanding questions: * To generate , an option must be explicitly supplied to dumps(). is always accepted, and it can't be turned off. Is this OK? * Similarly, allow_none is on or off for a ServerProxy; you can't turn it on for just one method. (Seems a reasonable limitation...) * Should the parameter to enable it be named allow_none (Python term) or allow_nil (XML-RPC term)? * When allow_none is false and a None is encountered, this patch raises a ValueError. Is that the right exception, or should it use xmlrpclib.Error? Can anyone suggest a better message for the exception? * The FastMarshaller accelerator would also need to be updated. * Are we ever likely to change the default for allow_none to True? If so, how should we arrange things so we can warn people? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-24 21:50 Message: Logged In: YES user_id=21627 On the exception: Currently, you get TypeError: cannot marshal objects and TypeError seems to be the right thing. The message might read cannot marshal None unless allow_none is enabled On allowing None by default: I'd assume that you would want to disable None only for "strictly-conforming" operation, so I'd expect to see an option strict (which then defaults to False). I don't know in what other ways we'd reasonably deviate from the spec. If that ever happens, I don't think a transitional warning is needed: existing applications continue to work. In general, in cases that produce an exception now, we don't need a transition procedure. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=628208&group_id=5470 From noreply@sourceforge.net Thu Oct 24 23:59:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Oct 2002 15:59:49 -0700 Subject: [Patches] [ python-Patches-628301 ] Experimental Inno Setup Win32 installer Message-ID: Patches item #628301, was opened at 2002-10-24 19:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=628301&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bruce Dodson (bdodson_esrican) Assigned to: Nobody/Anonymous (nobody) Summary: Experimental Inno Setup Win32 installer Initial Comment: I found the Inno Setup script for Python in the Python 2.2.1 source tree, and decided to hack on it a bit. Since I didn't want to deploy a custom build of Python (wanted to use the original), one of my changes is something you won't want: instead of looking in PCBuild etc. for the files, it expects the files to be laid out the way the WISE installer does it. However it should be easy to change this back so it works against the Python VC source / build tree. Be that as it may, this version has a few changes that you may or may not want: 1) incorporates Mark Hammond's win32 libraries (but not Pythonwin) 2) deletes PYC and PYO files on uninstall, so that the install directory can be properly removed. 3) uses Inno Setup Extensions (http://www.wintax.nl/isx) to enable scripted behavior, e.g. behave differently based on whether an administrator is running the install. 4) uses wildcards to make the script shorter. I do like the original author's idea of using a Python script to generate the ISS script; that would allow the files to be listed explicitly rather than relying on wildcards as I did here. The addition of Mark's stuff is something that interests me, since I can't redistribute ActivePython and find it cumbersome to include 2 installers plus my own; however it is not necessarily something that you are going to care about. The other changes may be more interesting to you. This script is based on the one found in Python 2.2.1 source tree, but I have compiled and tested it against Python 2.2.2. To test, run the Python WISE installer and Mark's win32all installer. Then copy python22.dll etc. from system32 to Python22\sysdir. Copy the ISS file into the Python22 directory. Running the ISX compiler against python.iss. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=628301&group_id=5470 From noreply@sourceforge.net Thu Oct 24 20:13:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Oct 2002 12:13:23 -0700 Subject: [Patches] [ python-Patches-562100 ] Installation database patch Message-ID: Patches item #562100, was opened at 2002-05-29 17:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=562100&group_id=5470 Category: Distutils and setup.py Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: A.M. Kuchling (akuchling) Summary: Installation database patch Initial Comment: The attached patch implements an installation database. This patch is not yet correct; don't bother proofreading it yet. I simply wanted to create a patch number so I could put it in PEP 262. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-10-24 15:13 Message: Logged In: YES user_id=11375 Closing this patch with the withdrawal of PEP 262. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=562100&group_id=5470 From noreply@sourceforge.net Thu Oct 24 20:50:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Oct 2002 12:50:33 -0700 Subject: [Patches] [ python-Patches-627105 ] warn about portability issue Message-ID: Patches item #627105, was opened at 2002-10-22 23:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=627105&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: warn about portability issue Initial Comment: It's conceivable that there is a platform with memory-protected pages smaller than 4 KB, and in that case if someone called PyObject_Free(p), where p pointed to an address towards the beginning of a page, the interpreter might incur a segment fault. This patch fixes the in-line docs so that it no longer incorrectly asserts that "It doesn't matter if this value is different from the native page size.". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-24 21:50 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=627105&group_id=5470 From noreply@sourceforge.net Thu Oct 24 20:55:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Oct 2002 12:55:19 -0700 Subject: [Patches] [ python-Patches-612627 ] Allow more Unicode on sys.stdout Message-ID: Patches item #612627, was opened at 2002-09-21 22:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612627&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: M.-A. Lemburg (lemburg) Summary: Allow more Unicode on sys.stdout Initial Comment: This patch extends the set of Unicode strings that can be printed to sys.stdout, to support all strings that the terminal will likely support. It also adds an encoding attribute to sys.std{in,out}. To do that: - it adds a .encoding attribute to all file objects, which is normally None - initializes the encoding of sys.stdin and sys.stdout if either is a terminal. - adds a wrapper object around sys.stdout in site.py that encodes all Unicode objects according to the detected encoding, if that encoding is known to Python To find the encoding of the terminal, it - uses GetConsoleCP and GetConsoleOutputCP on Windows, - uses nl_langinfo(CODESET) on Unix, if available. The primary rationale for this change is that people should be able to print Unicode in an interactive session. A parallel change needs to be added for IDLE, so that it adds the .encoding attribute to the emulated stdout (it already supports printing of Unicode on stdout). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-24 11:02 Message: Logged In: YES user_id=21627 I have considered implementing it in the file object. However, it becomes quite involved, and heavy C code: PyFile_WriteObject calls PyObject_Print. Since Unicode does not implement a tp_print, this calls str/repr, which converts using the default encoding. It is not clear at which point the file encoding should be taking into account. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-24 10:10 Message: Logged In: NO I like the .encoding concept. I don't really like the sys.stdout wrapper. Wouldn't it be better to add the functionality to the file object .write() and .writelines() methods and then only use the wrapper in case sys.stdout is not a true file object ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612627&group_id=5470 From noreply@sourceforge.net Fri Oct 25 10:21:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Oct 2002 02:21:32 -0700 Subject: [Patches] [ python-Patches-628301 ] Experimental Inno Setup Win32 installer Message-ID: Patches item #628301, was opened at 2002-10-24 22:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=628301&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bruce Dodson (bdodson_esrican) >Assigned to: Tim Peters (tim_one) Summary: Experimental Inno Setup Win32 installer Initial Comment: I found the Inno Setup script for Python in the Python 2.2.1 source tree, and decided to hack on it a bit. Since I didn't want to deploy a custom build of Python (wanted to use the original), one of my changes is something you won't want: instead of looking in PCBuild etc. for the files, it expects the files to be laid out the way the WISE installer does it. However it should be easy to change this back so it works against the Python VC source / build tree. Be that as it may, this version has a few changes that you may or may not want: 1) incorporates Mark Hammond's win32 libraries (but not Pythonwin) 2) deletes PYC and PYO files on uninstall, so that the install directory can be properly removed. 3) uses Inno Setup Extensions (http://www.wintax.nl/isx) to enable scripted behavior, e.g. behave differently based on whether an administrator is running the install. 4) uses wildcards to make the script shorter. I do like the original author's idea of using a Python script to generate the ISS script; that would allow the files to be listed explicitly rather than relying on wildcards as I did here. The addition of Mark's stuff is something that interests me, since I can't redistribute ActivePython and find it cumbersome to include 2 installers plus my own; however it is not necessarily something that you are going to care about. The other changes may be more interesting to you. This script is based on the one found in Python 2.2.1 source tree, but I have compiled and tested it against Python 2.2.2. To test, run the Python WISE installer and Mark's win32all installer. Then copy python22.dll etc. from system32 to Python22\sysdir. Copy the ISS file into the Python22 directory. Running the ISX compiler against python.iss. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=628301&group_id=5470 From noreply@sourceforge.net Thu Oct 24 20:33:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Oct 2002 12:33:11 -0700 Subject: [Patches] [ python-Patches-628208 ] xmlrpclib: Optional 'nil' support Message-ID: Patches item #628208, was opened at 2002-10-24 15:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=628208&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Fredrik Lundh (effbot) Summary: xmlrpclib: Optional 'nil' support Initial Comment: This patch doesn't include documentation or test suite updates yet, and only touches the < The extension is defined at http://ontosys.com/xml-rpc/extensions.html. Outstanding questions: * To generate , an option must be explicitly supplied to dumps(). is always accepted, and it can't be turned off. Is this OK? * Similarly, allow_none is on or off for a ServerProxy; you can't turn it on for just one method. (Seems a reasonable limitation...) * Should the parameter to enable it be named allow_none (Python term) or allow_nil (XML-RPC term)? * When allow_none is false and a None is encountered, this patch raises a ValueError. Is that the right exception, or should it use xmlrpclib.Error? Can anyone suggest a better message for the exception? * The FastMarshaller accelerator would also need to be updated. * Are we ever likely to change the default for allow_none to True? If so, how should we arrange things so we can warn people? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=628208&group_id=5470 From noreply@sourceforge.net Fri Oct 25 17:33:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Oct 2002 09:33:05 -0700 Subject: [Patches] [ python-Patches-627105 ] warn about portability issue Message-ID: Patches item #627105, was opened at 2002-10-22 21:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=627105&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: warn about portability issue Initial Comment: It's conceivable that there is a platform with memory-protected pages smaller than 4 KB, and in that case if someone called PyObject_Free(p), where p pointed to an address towards the beginning of a page, the interpreter might incur a segment fault. This patch fixes the in-line docs so that it no longer incorrectly asserts that "It doesn't matter if this value is different from the native page size.". ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2002-10-25 16:33 Message: Logged In: YES user_id=52562 Sorry about that. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-24 19:50 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=627105&group_id=5470 From noreply@sourceforge.net Fri Oct 25 13:09:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Oct 2002 05:09:03 -0700 Subject: [Patches] [ python-Patches-612627 ] Allow more Unicode on sys.stdout Message-ID: Patches item #612627, was opened at 2002-09-21 20:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612627&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Allow more Unicode on sys.stdout Initial Comment: This patch extends the set of Unicode strings that can be printed to sys.stdout, to support all strings that the terminal will likely support. It also adds an encoding attribute to sys.std{in,out}. To do that: - it adds a .encoding attribute to all file objects, which is normally None - initializes the encoding of sys.stdin and sys.stdout if either is a terminal. - adds a wrapper object around sys.stdout in site.py that encodes all Unicode objects according to the detected encoding, if that encoding is known to Python To find the encoding of the terminal, it - uses GetConsoleCP and GetConsoleOutputCP on Windows, - uses nl_langinfo(CODESET) on Unix, if available. The primary rationale for this change is that people should be able to print Unicode in an interactive session. A parallel change needs to be added for IDLE, so that it adds the .encoding attribute to the emulated stdout (it already supports printing of Unicode on stdout). ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-25 12:09 Message: Logged In: YES user_id=38388 I think it could work by adding a special case to PyFile_WriteObject() instead of calling PyObject_Print(). You first encode the Unicode object and then let PyFile_WriteString() take care of the writing to the FILE* object. I see no other way, since you can't place the .encoding information into the FILE* object. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-24 09:02 Message: Logged In: YES user_id=21627 I have considered implementing it in the file object. However, it becomes quite involved, and heavy C code: PyFile_WriteObject calls PyObject_Print. Since Unicode does not implement a tp_print, this calls str/repr, which converts using the default encoding. It is not clear at which point the file encoding should be taking into account. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-24 08:10 Message: Logged In: NO I like the .encoding concept. I don't really like the sys.stdout wrapper. Wouldn't it be better to add the functionality to the file object .write() and .writelines() methods and then only use the wrapper in case sys.stdout is not a true file object ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612627&group_id=5470 From noreply@sourceforge.net Fri Oct 25 16:03:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Oct 2002 08:03:17 -0700 Subject: [Patches] [ python-Patches-626485 ] Support Unicode normalization Message-ID: Patches item #626485, was opened at 2002-10-21 21:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626485&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Support Unicode normalization Initial Comment: This patch adds support for the normalization forms NFC, NFKC, NFD, NFKD. It passes the NormalizationTest-3.2.0.txt tests. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-25 17:03 Message: Logged In: YES user_id=21627 This patches addresses your issues in the following way: - single API: done. - add _getrecord_ex: done. Rename to getunicoderecord: since this is a static function in unicodedata.c, this renaming would not add that much information, so not done. - #ifdef Py_UNICODE_WIDE. I could not spot any place where this is necessary. - Drop -Latest: done. - adjust skip message: done. - reformat to 4 spaces: not done, I think PEP 7 should be followed. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-23 12:36 Message: Logged In: YES user_id=38388 One more minor nit: the indentation in the C file is 4 chars, please reindent your code accordingly ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-23 12:27 Message: Logged In: YES user_id=38388 The patch looks Ok except for a few nits: * I'd rather like a single API normalize(form) which takes the form as string argument instead of NFKD, etc. * __getrecord should be renamed to _getrecord_ex; perhaps both should use a different name altogether, e.g. getunicoderecord * I think you have to add some #ifdef Py_UNICODE_WIDE in the code to avoid compiler warnings for narrow builds about non-const if expressions being always true due to size limits. * The filenames you are using should not include the '-Latest' suffix. If you download the files from unicode.org via FTP they don't have this extension. * The skip test message should include a reference of where to get the test file from, ie. ftp://ftp.unicode.org/Public/UNIDATA/NormalizationTest.txt Thanks for working on this ! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=626485&group_id=5470 From noreply@sourceforge.net Sat Oct 26 01:10:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Oct 2002 17:10:25 -0700 Subject: [Patches] [ python-Patches-628898 ] Fix for bug 628890 Message-ID: Patches item #628898, was opened at 2002-10-26 08:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=628898&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Favas (mfavas) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for bug 628890 Initial Comment: This patch fixes the thread and posixmodule compilation failures on Tru64 Unix 4.0F reported in bug 628890. The fix requires changes to configure.in and pyconfig.h.in. The addition of "define _POSIX_C_SOURCE 199506L" fixes the thread test and compile issue, and the "#define _XOPEN_SOURCE_EXTENDED" fixes the posixmodule issue. ***NOTE*** The patch below is for configure, not configure.in - it wasn't clear to me where to patch it, and I don't have the autoconf tools to test it. The patch should be clear to anyone who understands autoconf better than I. *** pyconfig.h.in.orig Sat Oct 19 10:05:49 2002 --- pyconfig.h.in Sat Oct 19 17:33:01 2002 *************** *** 796,802 **** /* Define on UNIX to activate XPG/5 features. */ #ifndef _XOPEN_SOURCE ! # define _XOPEN_SOURCE 500 #endif /* Define to 1 if type `char' is unsigned and you are not using gcc. */ --- 796,804 ---- /* Define on UNIX to activate XPG/5 features. */ #ifndef _XOPEN_SOURCE ! #define _POSIX_C_SOURCE 199506L ! #define _XOPEN_SOURCE 500 ! #define _XOPEN_SOURCE_EXTENDED #endif /* Define to 1 if type `char' is unsigned and you are not using gcc. */ *** configure.orig Sat Oct 19 06:43:17 2002 --- configure Sat Oct 19 17:33:09 2002 *************** *** 1238,1244 **** --- 1238,1246 ---- cat >>confdefs.h <<\_ACEOF + #define _POSIX_C_SOURCE 199506L #define _XOPEN_SOURCE 500 + #define _XOPEN_SOURCE_EXTENDED _ACEOF ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=628898&group_id=5470 From noreply@sourceforge.net Sat Oct 26 14:35:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Oct 2002 06:35:22 -0700 Subject: [Patches] [ python-Patches-628898 ] Fix for bug 628890 Message-ID: Patches item #628898, was opened at 2002-10-26 02:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=628898&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Mark Favas (mfavas) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for bug 628890 Initial Comment: This patch fixes the thread and posixmodule compilation failures on Tru64 Unix 4.0F reported in bug 628890. The fix requires changes to configure.in and pyconfig.h.in. The addition of "define _POSIX_C_SOURCE 199506L" fixes the thread test and compile issue, and the "#define _XOPEN_SOURCE_EXTENDED" fixes the posixmodule issue. ***NOTE*** The patch below is for configure, not configure.in - it wasn't clear to me where to patch it, and I don't have the autoconf tools to test it. The patch should be clear to anyone who understands autoconf better than I. *** pyconfig.h.in.orig Sat Oct 19 10:05:49 2002 --- pyconfig.h.in Sat Oct 19 17:33:01 2002 *************** *** 796,802 **** /* Define on UNIX to activate XPG/5 features. */ #ifndef _XOPEN_SOURCE ! # define _XOPEN_SOURCE 500 #endif /* Define to 1 if type `char' is unsigned and you are not using gcc. */ --- 796,804 ---- /* Define on UNIX to activate XPG/5 features. */ #ifndef _XOPEN_SOURCE ! #define _POSIX_C_SOURCE 199506L ! #define _XOPEN_SOURCE 500 ! #define _XOPEN_SOURCE_EXTENDED #endif /* Define to 1 if type `char' is unsigned and you are not using gcc. */ *** configure.orig Sat Oct 19 06:43:17 2002 --- configure Sat Oct 19 17:33:09 2002 *************** *** 1238,1244 **** --- 1238,1246 ---- cat >>confdefs.h <<\_ACEOF + #define _POSIX_C_SOURCE 199506L #define _XOPEN_SOURCE 500 + #define _XOPEN_SOURCE_EXTENDED _ACEOF ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-26 15:35 Message: Logged In: YES user_id=21627 Rewritten for autoconf, and committed as configure.in 1.359; configure 1.348; pyconfig.h.in 1.56; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=628898&group_id=5470 From noreply@sourceforge.net Sat Oct 26 14:49:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Oct 2002 06:49:11 -0700 Subject: [Patches] [ python-Patches-623771 ] autoconf-2.5X tweaks for configure.in Message-ID: Patches item #623771, was opened at 2002-10-15 23:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=623771&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Art Haas (ahaas) Assigned to: Martin v. Löwis (loewis) Summary: autoconf-2.5X tweaks for configure.in Initial Comment: Hi. Here's a small patch that adjust AC_INIT and AC_OUTPUT from the autoconf-2.13 style to the new autoconf-2.5X style. In changing these macros to their new format, the addition of AC_CONFIG_SRCDIR and AC_CONFIG_FILES is required. I've also removed the VERSION macro as that value can be defined in the second argument of AC_INIT. Art Haas ahaas@neosoft.com ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-26 15:49 Message: Logged In: YES user_id=21627 I have committed something like this as configure.in 1.360; configure 1.349; The version computation appeared to me overly complex, and I've omitted the bug report address: the info documentation says this should be an email address, not an URL. ---------------------------------------------------------------------- Comment By: Art Haas (ahaas) Date: 2002-10-17 17:55 Message: Logged In: YES user_id=629911 My Makefile has a blank VERSION also, so I see that the part of the patch where I removed the VERSION variable is wrong. I'm attaching a new patch for the AC_INIT bits of configure.in. In this patch, there are a couple of variables defined using m4_define(), and these are then used to provide the version argument for AC_INIT and the value for the VERSION variable. After rebuilding configure with this patch, the variable VERSION in the Makefile is set to 2.3, as it should be. The AC_OUTPUT changes from the first patch are still good. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-16 21:32 Message: Logged In: YES user_id=21627 Can you please verify the setting of VERSION in your generate Makefile? When I use your patch, I get VERSION= whereas I should get VERSION= 2.3 Also, can you please use autoconf 2.53? This is the version that Python is currently is developed with, and we cannot make use of strategies or features that are available in 2.54 only. ---------------------------------------------------------------------- Comment By: Art Haas (ahaas) Date: 2002-10-16 18:44 Message: Logged In: YES user_id=629911 Hi. I did test this, and it worked fine - as far as I could tell. The autoconf docs I have (autoconf-2.54) show that AC_INIT is defined like ... AC_INIT (PACKAGE, VERSION, [BUG-REPORT], [TARNAME]) ... and PACKAGE_VERSION is taken from VERSION. I suppose that if there is a conflict, then the variable VERSION can be directly defined after AC_INIT, and it can be specified to whatever is needed to avoid the problems you see. Still, the format for the AC_INIT macro as it exists now is obsolete, so I believe it's better to change to the current format. Changing AC_OUTPUT to the current style is also a good move IMHO. There's another change I'd also suggest - renaming configure.in to configure.ac, as autoconf now suggests the ".ac" extension. That can be done later. Art Haas ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-16 13:22 Message: Logged In: YES user_id=21627 It appears that you did not test this change. AC_INIT does not define VERSION, but PACKAGE_VERSION. Even if this is fixed (somehow), the resulting pyconfig.h will be installed, and then conflict in its PACKAGE_VERSION definition with other packages which also use autoconf. So I'm not sure this should be done at all. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=623771&group_id=5470 From noreply@sourceforge.net Sat Oct 26 15:44:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Oct 2002 07:44:46 -0700 Subject: [Patches] [ python-Patches-512981 ] readline /dev/tty problem Message-ID: Patches item #512981, was opened at 2002-02-04 22:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=512981&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Daniel Stutzbach (agthorr) Assigned to: Martin v. Löwis (loewis) Summary: readline /dev/tty problem Initial Comment: GNU readline doesn't work if the C symbol "stdin" is not a tty, even if the python symbol sys.stdin is. This will happen, for example, if a program initially receives input from a pipe, but then changes sys.stdin to read from /dev/tty. (This is how programs like "less" work) Here's a sample program that exhibits this behavior: ------------------------------------------------------------------------ #!/usr/bin/env python import sys mail = sys.stdin.read () sys.stdin = open ('/dev/tty', 'r') import readline foo = raw_input ('add_idea> ') print foo ------------------------------------------------------------------------ You can test this by saving the above program to a file (foo.py), piping data to it, then trying to use GNU readline editing commands at the prompt. E.g.: ------------------------------------------------------------------------ liberty:~$ cat ideas.html | ./foo.py add_idea> asdfsdf^Afoo asdfsdffoo ------------------------------------------------------------------------ The patch attached seems to fix the problem. You may want to grep the source for other modules that may have similar bugs. Also, this patch assumes that the readline module is imported *after* sys.stdin is changed. This much better than nothing (particularly if it's documented), but there may be a better solution. -- Agthorr ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-26 16:44 Message: Logged In: YES user_id=21627 Thanks for the patch, committed as pythonrun.h 2.55; readline.c 2.54; myreadline.c 2.28; tokenizer.c 2.68; bltinmodule.c 2.266; NEWS 1.503; ACKS 2.212 The limitation (interpreter continues to read from stdin) seems reasonable. ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-10-14 07:12 Message: Logged In: YES user_id=6324 When in interactive mode, if the user changes sys.std[in|out], would you agree that the interpreter should continue using C std[in|out] to get commands? (this is the current behavior without my patch) The documentation for sys.std[in|out|err] seem to suggest one should be able to redirect them, but I'm not sure that's actually desirable. (Your example only crashes if the interpreter is in interactive mode.) I've included another patch assuming this is the desired behavior. I tried several permutations of interactive vs non-interactive, setting sys.stdin and/or sys.stdout to None, and doing this before and after initializing readline. ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-10-13 19:24 Message: Logged In: YES user_id=6324 Jeez. My apologies. I will submit a new patch within a few days, and this time I will do regression testing instead of just looking at the problem I was trying to fix. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 12:44 Message: Logged In: YES user_id=21627 It appears that your patch can crash when sys.stdin/out is not a file anymore: >>> import readline >>> import codecs,sys >>> sys.stdout=codecs.getwriter('utf-8')(sys.stdout) Segmentation fault (core dumped) ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-10-11 09:23 Message: Logged In: YES user_id=6324 Okay, I've attached a new patch that works as you suggested. Let me know if you have any questions or concerns. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-08 11:27 Message: Logged In: YES user_id=21627 I think you should implement a strategy to detect changes to sys.stdin dynamically. For example, the old sys.stdin could go away, closing the file, which would leave readline with a garbage pointer. Instead, I think you should hold onto sys.stdin, and compare this reference from time to time with the current sys.stdin, and arrange to reinitialize readline (if possible). ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-10-07 23:32 Message: Logged In: YES user_id=6324 Yes, I'm interested in pursuing it. Let me know what I can do to move this along. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 23:15 Message: Logged In: YES user_id=21627 Are you interested in pursuing this feature? I cannot promise that I will apply it blankly, only that I will review it. ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-04-25 22:02 Message: Logged In: YES user_id=6324 If I create a patch that operates as described in my previous followup, will you apply it? Is there anything I can do to get this integrated into the main python trunk? I don't like having to repatch and rebuild python everytime a new version comes out that I need for some other reason :> ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2002-02-05 19:21 Message: Logged In: YES user_id=6324 1) Well, it lets python treat sys.stdin as a tty even if C stdin != python sys.stdin. It still checks to make sure sys.stdin is a tty using isatty(). If some user changes sys.stdin to point to a tty, but *wants* Python to treat it as a non-tty, then this might cause them some grief. I can't think of any case where they'd want to do that, though. The behavior would be unchanged when sys.stdin points to a regular file. 2) hmm.. I suppose, ideally, the readline module should smoothly handle sys.stdin being changed out from under it. Readline alters various terminal settings on rl_instream during initialization, though. For example, it changes the terminal to raw or cbreak mode from cooked mode, so that it can receive input a character at a time instead of a line at a time. It may be possible to uninitialized and reinitialized terminal each time call_readline is called, I suppose (I believe libreadline provides hooks for this). It would also have to check if sys.stdin is a tty, and call PyFile_GetLine if it is not. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-02-05 11:35 Message: Logged In: YES user_id=6656 Comments: 1) in what ways does this change existing behaviour? I can think of a few, but are there any that will inconvenience existing users 2) why not do the rl_instream = PySys_GetObject("stdin") dance in call_readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=512981&group_id=5470 From noreply@sourceforge.net Sat Oct 26 15:52:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Oct 2002 07:52:19 -0700 Subject: [Patches] [ python-Patches-613256 ] add unescape method to xml.sax.saxutils Message-ID: Patches item #613256, was opened at 2002-09-23 17:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613256&group_id=5470 Category: XML Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Matthew Boedicker (mboedick) Assigned to: Martin v. Löwis (loewis) Summary: add unescape method to xml.sax.saxutils Initial Comment: This patch adds an unescape() method to saxutils to convert an xml-escaped string back to its original form It also modifies the escape() method so that the core escaping takes places after any additional escaping passed in via the dictionary. This will guarantee that returned string is properly escaped for xml no matter what is passed in via the dictionary. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-26 16:52 Message: Logged In: YES user_id=21627 Thanks for the patch, committed as xmlsaxutils.tex 1.4; test_sax.py 1.23; output/test_sax 1.11; saxutils.py 1.17; ACKS 1.213; NEWS 1.504; ---------------------------------------------------------------------- Comment By: Matthew Boedicker (mboedick) Date: 2002-10-15 21:43 Message: Logged In: YES user_id=119895 added documentation and test cases no longer changes the order in which escape() modifies the string with core and passed-in replacements ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 14:53 Message: Logged In: YES user_id=21627 Can you please provide documentation and test cases? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613256&group_id=5470 From noreply@sourceforge.net Sat Oct 26 16:02:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Oct 2002 08:02:23 -0700 Subject: [Patches] [ python-Patches-627105 ] warn about portability issue Message-ID: Patches item #627105, was opened at 2002-10-22 23:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=627105&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: warn about portability issue Initial Comment: It's conceivable that there is a platform with memory-protected pages smaller than 4 KB, and in that case if someone called PyObject_Free(p), where p pointed to an address towards the beginning of a page, the interpreter might incur a segment fault. This patch fixes the in-line docs so that it no longer incorrectly asserts that "It doesn't matter if this value is different from the native page size.". ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-26 17:02 Message: Logged In: YES user_id=21627 Thanks for the patch, applied as obmalloc.c 2.49. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2002-10-25 18:33 Message: Logged In: YES user_id=52562 Sorry about that. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-24 21:50 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=627105&group_id=5470 From noreply@sourceforge.net Sat Oct 26 16:09:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Oct 2002 08:09:28 -0700 Subject: [Patches] [ python-Patches-486438 ] makes doctest.testmod() to work Message-ID: Patches item #486438, was opened at 2001-11-28 13:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=486438&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: Postponed Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Tim Peters (tim_one) Summary: makes doctest.testmod() to work Initial Comment: testmod() can now be called with no arguments, in which case it works on the current module. This is a big convenience for self-testing modules. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-26 17:09 Message: Logged In: YES user_id=21627 Tim, is there anything wrong with this patch? I recommend to accept it as-is. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-25 20:10 Message: Logged In: YES user_id=31435 Yup, it's stuck at Postponed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-25 20:09 Message: Logged In: YES user_id=31435 Now that 2.2 is out, changed the Postponed status back to None (although I fear it may remain Postponed anyway -- SF doesn't seem to like resetting a Resolution to None). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-28 18:34 Message: Logged In: YES user_id=31435 Assigned to me, and Postponed (2.2 is in feature freeze). When resurrected, will try to find Skip's old patch (email'ed?) for this and combine them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=486438&group_id=5470 From noreply@sourceforge.net Sat Oct 26 16:23:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Oct 2002 08:23:50 -0700 Subject: [Patches] [ python-Patches-473586 ] SimpleXMLRPCServer - fixes and CGI Message-ID: Patches item #473586, was opened at 2001-10-22 09:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=473586&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Fredrik Lundh (effbot) Summary: SimpleXMLRPCServer - fixes and CGI Initial Comment: Changes: o treats xmlrpclib.Fault's correctly (no longer absorbes them as generic exceptions) o changed failed marshal to generate a useful Fault instead of an internal server error o adds a new class to make writing XML-RPC functions embedded in other servers, using CGI, easier (tested with APACHE) o to support the above, added a new dispatch helper class SimpleXMLRPCDispatcher ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-26 17:23 Message: Logged In: YES user_id=21627 Brian, the patch looks good to me. However, can you please also supply patches to Doc/lib/libsimplexmlrpc? ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2002-03-18 20:41 Message: Logged In: YES user_id=108973 OK, I fixed the backwards compatibility problem. Also added: o support for the XML-RPC introspection methods system.listMethods and system.methodHelp o support for the XML-RPC boxcaring method system.multicall ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-12-04 20:51 Message: Logged In: YES user_id=108973 Please do not accept this patch past 2.2 release; there are so non-backwards compatible changes that need to be though through. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-23 20:02 Message: Logged In: YES user_id=108973 - a few extra comments - moved a xmlrpclib.loads() inside an exception handler so an XML-RPC fault is generated for malformed requests ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-22 20:59 Message: Logged In: YES user_id=108973 The advantage of the entire patch being accepted before 2.2 is that there is an API change and, once 2.2 is release, we will probably have to make a bit of an attempt to maintain backwards compatibility. If this patch is too high-risk for 2.2 then I can certainly design a bug-fix patch for 2.2 and submit a new patch for 2.3 (that is API compatible with 2.2). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-22 20:43 Message: Logged In: YES user_id=21627 Brian, please note that Python 2.2b1 has been released, so no new features are acceptable until 2.2. So unless Fredrik Lundh wants to accept your entire patch, I think it has little chance to get integrated for the next few months. If you want pieces of it accepted, I'd recommend to split it into bug fixes and new features; bug fixes are still acceptable. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-22 20:27 Message: Logged In: YES user_id=108973 I just can't stop mucking with it. This time there are only documentation changes. I should also have pointed out that this patch changes the mechanism for overriding the dispatch mechanism: you used to subclass the request handler, now you subclass the server. I believe that this change is correct because the server actually has the required state information to do the dispatching. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-22 09:35 Message: Logged In: YES user_id=108973 Changed a name to fit other naming conventions ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=473586&group_id=5470 From noreply@sourceforge.net Sat Oct 26 17:09:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Oct 2002 09:09:35 -0700 Subject: [Patches] [ python-Patches-629126 ] Detect BLT on more systems Message-ID: Patches item #629126, was opened at 2002-10-26 17:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629126&group_id=5470 Category: Distutils and setup.py Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: David Buscher (dbuscher) Assigned to: Nobody/Anonymous (nobody) Summary: Detect BLT on more systems Initial Comment: setup.py for python 2.2 does not detect the BLT add-on to tk unless it is named libBLT8.0, which is not the case on many (most?) systems including Redhat Linux. This patch detects libBLT8.0.{so,a} first but accepts libBLT.{so,a} as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629126&group_id=5470 From noreply@sourceforge.net Sat Oct 26 18:47:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Oct 2002 10:47:09 -0700 Subject: [Patches] [ python-Patches-612627 ] Allow more Unicode on sys.stdout Message-ID: Patches item #612627, was opened at 2002-09-21 22:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612627&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Allow more Unicode on sys.stdout Initial Comment: This patch extends the set of Unicode strings that can be printed to sys.stdout, to support all strings that the terminal will likely support. It also adds an encoding attribute to sys.std{in,out}. To do that: - it adds a .encoding attribute to all file objects, which is normally None - initializes the encoding of sys.stdin and sys.stdout if either is a terminal. - adds a wrapper object around sys.stdout in site.py that encodes all Unicode objects according to the detected encoding, if that encoding is known to Python To find the encoding of the terminal, it - uses GetConsoleCP and GetConsoleOutputCP on Windows, - uses nl_langinfo(CODESET) on Unix, if available. The primary rationale for this change is that people should be able to print Unicode in an interactive session. A parallel change needs to be added for IDLE, so that it adds the .encoding attribute to the emulated stdout (it already supports printing of Unicode on stdout). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-26 19:47 Message: Logged In: YES user_id=21627 I've attached a revised version which implements your proposal; this version works without modification of site.py. In its current form, the file encoding is only applied in print; for sys.stdout.write, it is ignored. For print, it is applied independent of whether this is a script or interactive mode. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-25 14:09 Message: Logged In: YES user_id=38388 I think it could work by adding a special case to PyFile_WriteObject() instead of calling PyObject_Print(). You first encode the Unicode object and then let PyFile_WriteString() take care of the writing to the FILE* object. I see no other way, since you can't place the .encoding information into the FILE* object. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-24 11:02 Message: Logged In: YES user_id=21627 I have considered implementing it in the file object. However, it becomes quite involved, and heavy C code: PyFile_WriteObject calls PyObject_Print. Since Unicode does not implement a tp_print, this calls str/repr, which converts using the default encoding. It is not clear at which point the file encoding should be taking into account. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-24 10:10 Message: Logged In: NO I like the .encoding concept. I don't really like the sys.stdout wrapper. Wouldn't it be better to add the functionality to the file object .write() and .writelines() methods and then only use the wrapper in case sys.stdout is not a true file object ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612627&group_id=5470 From noreply@sourceforge.net Sun Oct 27 01:03:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Oct 2002 17:03:42 -0700 Subject: [Patches] [ python-Patches-629278 ] install lib-dynload .so files mode 555 Message-ID: Patches item #629278, was opened at 2002-10-26 19:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629278&group_id=5470 Category: Distutils and setup.py Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: J. Lewis Muir (jlmuir) Assigned to: Nobody/Anonymous (nobody) Summary: install lib-dynload .so files mode 555 Initial Comment: This is a patch to the setup.py file to set the permissions of the installed shared libraries to have mode 555 (r xr xr x). This fixes bug #549338 "lib-dynload/*.so permissions wrong" and a duplicate bug #583206 "lib-dynload/*.so wrong permissions". The problem was that the shared libraries are installed by simply copying the tree of built shared libraries from the build directory to the installation location. This means that the permissions of the installed shared library files will be whatever the permissions were on these files in the build directory. The permissions are never set. If the shared libraries do not have the execute bit set, then on some platforms (Linux, in my case), python will be broken. For example, if one tries to import the time module, python will raise an ImportError saying "No module named time". To fix this, I've added a class PyBuildInstallLib(install_lib) which does exactly what install_lib does by invoking the super implementation of the install method, but then sets the permissions correctly for the installed shared library files. In the setup call in the main function, I pass this PyBuildInstallLib class in the cmdclass dictionary as the class that should be used for the 'install_lib' command. Another approach would be to instead modify the Makefile to set the correct file modes of the installed shared library files in the 'sharedinstall' target right after running '... setup.py install ...'. I didn't do this because it seemed other file modes were being set by other commands in distutils so it seemed appropriate to do the same. Attached is a patch against the 2.2.2 release. This I have tested on my machine (x86, Mandrake 8.0 + updates, Linux 2.4.18). I've also looked at what's in CVS and my changes can be trivially made to the setup.py that's in CVS as of Sat 2002-10-26 5pm CDT. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629278&group_id=5470 From noreply@sourceforge.net Sun Oct 27 14:39:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Oct 2002 06:39:11 -0800 Subject: [Patches] [ python-Patches-590377 ] db4 include not found Message-ID: Patches item #590377, was opened at 2002-08-02 16:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: Invalid Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: db4 include not found Initial Comment: setup.py looks for the db4 library in /usr/lib, but doesn't look for the header in /usr/include (as you find it on Debian unstable) ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-10-27 08:39 Message: Logged In: YES user_id=44345 Is /usr/include/db.h a symlink to some other file on Debian which is version-specific? If so, I'd be happy to add that directory to the list searched. How does Debian structure its directories to allow multiple versions of Berkeley db to be installed simultaneously? If /usr/include/db.h is the location of the include file, is /usr/lib/libdb.{so,a} the location of the library? The original (db1) versions of Berkeley DB generally had db.h in /usr/include. This version is, unfortunately, both broken and still in use. Other vendors allow multiple versions of the library to be installed, and use a version-specific directory naming scheme to keep things sorted out. Debian could do the same. No matter how strongly you believe /usr/include should be searched, I'm not going to add it by default and risk the chance that other peoples' installs break (silently) as a result. Please read the comments related to db1 in setup.py. (Search for bsddb.) Final thought here... Doesn't Debian have and base+patch sort of system? To install on Debian, all that would need to be done is develop a Debian-specific patch which adds /usr/include to the incdirs key and something like 'db' to the libs key in the db4 section. Skip ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-21 17:11 Message: Logged In: YES user_id=21627 As a bug report, I would close this as "Won't fix", pointing you to the option of not using setup.py, but compiling the module through Modules/Setup. I'd prefer to get a patch, but that should be one that works on all systems. This one breaks on systems where /usr/include/db.h is not a bsddb 4 header file. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-21 16:54 Message: Logged In: YES user_id=60903 > - Doesn't it cause -I/usr/include be added to the > compilation statement? yes, that's not correct > - Why is that done for db4 and not db3? On Debian only one libdb-dev package can be installed at build time. I assure with the build dependencies that I get the correct one. > - How can we know what bsddb version /usr/include/db.h > belongs to? Guessing that it is db4 is error-prone, so it > might be, in fact, better not to find that file. maybe grep for DB_VERSION_MAJOR in the file? I admit, this issue should be a bug report, not a patch ... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-21 16:42 Message: Logged In: YES user_id=21627 Ok, I admit that the patch might be needed; I think it is quite incorrect, though: - Doesn't it cause -I/usr/include be added to the compilation statement? - Why is that done for db4 and not db3? - How can we know what bsddb version /usr/include/db.h belongs to? Guessing that it is db4 is error-prone, so it might be, in fact, better not to find that file. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-21 16:14 Message: Logged In: YES user_id=60903 Martin, you're closing reports very quickly ;-) What makes you think the problem is solved? The code doesn't search /usr/include for db.h. Updated patch included. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 08:06 Message: Logged In: YES user_id=21627 The patch is out-of-date, and appears to be unnecessary. I'm rejecting it - if you still think something needs to be done, please submit a new patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470 From noreply@sourceforge.net Sun Oct 27 15:12:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Oct 2002 07:12:20 -0800 Subject: [Patches] [ python-Patches-590377 ] db4 include not found Message-ID: Patches item #590377, was opened at 2002-08-02 23:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: Invalid Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: db4 include not found Initial Comment: setup.py looks for the db4 library in /usr/lib, but doesn't look for the header in /usr/include (as you find it on Debian unstable) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-27 16:12 Message: Logged In: YES user_id=21627 /usr/include/db.h is not a symlink; it is the file itself. You cannot have multiple bsddb development packages (libdbX-dev) installed, because they conflict with each other. /usr/lib/libdb.so exists and is a symlink to the installed shared library. The file in question isn't actually db.h (for current bsddbmodule.c), but db_185.h, of course. As for base+patch: Sure, Debian already uses such a patch. Matthias is the Debian maintainer of Python, and asks us (as upstream) to include his patch. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-27 15:39 Message: Logged In: YES user_id=44345 Is /usr/include/db.h a symlink to some other file on Debian which is version-specific? If so, I'd be happy to add that directory to the list searched. How does Debian structure its directories to allow multiple versions of Berkeley db to be installed simultaneously? If /usr/include/db.h is the location of the include file, is /usr/lib/libdb.{so,a} the location of the library? The original (db1) versions of Berkeley DB generally had db.h in /usr/include. This version is, unfortunately, both broken and still in use. Other vendors allow multiple versions of the library to be installed, and use a version-specific directory naming scheme to keep things sorted out. Debian could do the same. No matter how strongly you believe /usr/include should be searched, I'm not going to add it by default and risk the chance that other peoples' installs break (silently) as a result. Please read the comments related to db1 in setup.py. (Search for bsddb.) Final thought here... Doesn't Debian have and base+patch sort of system? To install on Debian, all that would need to be done is develop a Debian-specific patch which adds /usr/include to the incdirs key and something like 'db' to the libs key in the db4 section. Skip ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-22 00:11 Message: Logged In: YES user_id=21627 As a bug report, I would close this as "Won't fix", pointing you to the option of not using setup.py, but compiling the module through Modules/Setup. I'd prefer to get a patch, but that should be one that works on all systems. This one breaks on systems where /usr/include/db.h is not a bsddb 4 header file. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-21 23:54 Message: Logged In: YES user_id=60903 > - Doesn't it cause -I/usr/include be added to the > compilation statement? yes, that's not correct > - Why is that done for db4 and not db3? On Debian only one libdb-dev package can be installed at build time. I assure with the build dependencies that I get the correct one. > - How can we know what bsddb version /usr/include/db.h > belongs to? Guessing that it is db4 is error-prone, so it > might be, in fact, better not to find that file. maybe grep for DB_VERSION_MAJOR in the file? I admit, this issue should be a bug report, not a patch ... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-21 23:42 Message: Logged In: YES user_id=21627 Ok, I admit that the patch might be needed; I think it is quite incorrect, though: - Doesn't it cause -I/usr/include be added to the compilation statement? - Why is that done for db4 and not db3? - How can we know what bsddb version /usr/include/db.h belongs to? Guessing that it is db4 is error-prone, so it might be, in fact, better not to find that file. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-21 23:14 Message: Logged In: YES user_id=60903 Martin, you're closing reports very quickly ;-) What makes you think the problem is solved? The code doesn't search /usr/include for db.h. Updated patch included. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 15:06 Message: Logged In: YES user_id=21627 The patch is out-of-date, and appears to be unnecessary. I'm rejecting it - if you still think something needs to be done, please submit a new patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470 From noreply@sourceforge.net Sun Oct 27 15:36:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Oct 2002 07:36:40 -0800 Subject: [Patches] [ python-Patches-629426 ] autoconf-2.5X mods for configure.in Message-ID: Patches item #629426, was opened at 2002-10-27 09:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629426&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Art Haas (ahaas) Assigned to: Nobody/Anonymous (nobody) Summary: autoconf-2.5X mods for configure.in Initial Comment: Hi. Here's another patch for configure.in that replaces a few more obsolete macros ... AC_CONFIG_HEADER ==> AC_CONFIG_HEADERS AC_ERROR ==> AC_MSG_ERROR There are a couple of uses of AC_MSG_RESULT that had unecessary escaped quotes, so I removed them. These were pointed out when running "autoconf --warnings=all". This patch also adds the AC_HELP_STRING macro in most of the AC_ARG_* macros. This macro is designed to format the output the configure script presents when invoked "configure --help". In adding this macro I've added a few more explicit quotes in some of the AC_ARG_* macros also. The AC_HELP_STRING macro itself though is not quoted (unlike nearly every other macro in autoconf-2.5X) as this is specified by the autoconf docs. A couple of places in the patch have "@<:@" and "@:>@". These are autoconf quadrigraphs that expand to "[' and "]" in the configure script. I used them so the "--help" output would retain the square brackets in places it does currently. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629426&group_id=5470 From noreply@sourceforge.net Sun Oct 27 15:46:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Oct 2002 07:46:11 -0800 Subject: [Patches] [ python-Patches-590377 ] db4 include not found Message-ID: Patches item #590377, was opened at 2002-08-02 16:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: Invalid Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: db4 include not found Initial Comment: setup.py looks for the db4 library in /usr/lib, but doesn't look for the header in /usr/include (as you find it on Debian unstable) ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-10-27 09:46 Message: Logged In: YES user_id=44345 It's clear we can't blindly add '/usr/include' to db_try_this['db4']['incdirs'] and 'db' to db_try_this['db4']['libs']. Is there some way to unambiguously detect from setup.py that Python is being built on a Debian system and that we are not dealing with an installation of db1 (which I still refuse to enable without manual intervention)? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-27 09:12 Message: Logged In: YES user_id=21627 /usr/include/db.h is not a symlink; it is the file itself. You cannot have multiple bsddb development packages (libdbX-dev) installed, because they conflict with each other. /usr/lib/libdb.so exists and is a symlink to the installed shared library. The file in question isn't actually db.h (for current bsddbmodule.c), but db_185.h, of course. As for base+patch: Sure, Debian already uses such a patch. Matthias is the Debian maintainer of Python, and asks us (as upstream) to include his patch. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-27 08:39 Message: Logged In: YES user_id=44345 Is /usr/include/db.h a symlink to some other file on Debian which is version-specific? If so, I'd be happy to add that directory to the list searched. How does Debian structure its directories to allow multiple versions of Berkeley db to be installed simultaneously? If /usr/include/db.h is the location of the include file, is /usr/lib/libdb.{so,a} the location of the library? The original (db1) versions of Berkeley DB generally had db.h in /usr/include. This version is, unfortunately, both broken and still in use. Other vendors allow multiple versions of the library to be installed, and use a version-specific directory naming scheme to keep things sorted out. Debian could do the same. No matter how strongly you believe /usr/include should be searched, I'm not going to add it by default and risk the chance that other peoples' installs break (silently) as a result. Please read the comments related to db1 in setup.py. (Search for bsddb.) Final thought here... Doesn't Debian have and base+patch sort of system? To install on Debian, all that would need to be done is develop a Debian-specific patch which adds /usr/include to the incdirs key and something like 'db' to the libs key in the db4 section. Skip ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-21 17:11 Message: Logged In: YES user_id=21627 As a bug report, I would close this as "Won't fix", pointing you to the option of not using setup.py, but compiling the module through Modules/Setup. I'd prefer to get a patch, but that should be one that works on all systems. This one breaks on systems where /usr/include/db.h is not a bsddb 4 header file. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-21 16:54 Message: Logged In: YES user_id=60903 > - Doesn't it cause -I/usr/include be added to the > compilation statement? yes, that's not correct > - Why is that done for db4 and not db3? On Debian only one libdb-dev package can be installed at build time. I assure with the build dependencies that I get the correct one. > - How can we know what bsddb version /usr/include/db.h > belongs to? Guessing that it is db4 is error-prone, so it > might be, in fact, better not to find that file. maybe grep for DB_VERSION_MAJOR in the file? I admit, this issue should be a bug report, not a patch ... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-21 16:42 Message: Logged In: YES user_id=21627 Ok, I admit that the patch might be needed; I think it is quite incorrect, though: - Doesn't it cause -I/usr/include be added to the compilation statement? - Why is that done for db4 and not db3? - How can we know what bsddb version /usr/include/db.h belongs to? Guessing that it is db4 is error-prone, so it might be, in fact, better not to find that file. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-21 16:14 Message: Logged In: YES user_id=60903 Martin, you're closing reports very quickly ;-) What makes you think the problem is solved? The code doesn't search /usr/include for db.h. Updated patch included. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 08:06 Message: Logged In: YES user_id=21627 The patch is out-of-date, and appears to be unnecessary. I'm rejecting it - if you still think something needs to be done, please submit a new patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470 From noreply@sourceforge.net Sun Oct 27 19:33:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Oct 2002 11:33:57 -0800 Subject: [Patches] [ python-Patches-629426 ] autoconf-2.5X mods for configure.in Message-ID: Patches item #629426, was opened at 2002-10-27 16:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629426&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Art Haas (ahaas) Assigned to: Nobody/Anonymous (nobody) Summary: autoconf-2.5X mods for configure.in Initial Comment: Hi. Here's another patch for configure.in that replaces a few more obsolete macros ... AC_CONFIG_HEADER ==> AC_CONFIG_HEADERS AC_ERROR ==> AC_MSG_ERROR There are a couple of uses of AC_MSG_RESULT that had unecessary escaped quotes, so I removed them. These were pointed out when running "autoconf --warnings=all". This patch also adds the AC_HELP_STRING macro in most of the AC_ARG_* macros. This macro is designed to format the output the configure script presents when invoked "configure --help". In adding this macro I've added a few more explicit quotes in some of the AC_ARG_* macros also. The AC_HELP_STRING macro itself though is not quoted (unlike nearly every other macro in autoconf-2.5X) as this is specified by the autoconf docs. A couple of places in the patch have "@<:@" and "@:>@". These are autoconf quadrigraphs that expand to "[' and "]" in the configure script. I used them so the "--help" output would retain the square brackets in places it does currently. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-27 20:33 Message: Logged In: YES user_id=21627 I'm with you for most of these changes. However: - where does it say that AC_CONFIG_HEADER is obsolete? We only have one header. - Please avoid unnecessary quoting. I.e. don't write AC_HELP_STRING([--without-gcc], [never use gcc]), but write AC_HELP(--without-gcc, never use gcc) (Quoting spaced strings is perhaps acceptable; quoting individual words is not) - Those quadrigraphs look terrible. Try using changequote instead (e.g. to <<,>>) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629426&group_id=5470 From noreply@sourceforge.net Mon Oct 28 01:54:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Oct 2002 17:54:07 -0800 Subject: [Patches] [ python-Patches-629632 ] Build error on *BSDs with _POSIX_C_SOURC Message-ID: Patches item #629632, was opened at 2002-10-28 10:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629632&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Build error on *BSDs with _POSIX_C_SOURC Initial Comment: FreeBSD and NetBSD hides non-POSIX functions when _POSIX_C_SOURCE or _POSIX_SOURCE is defined. As a result, posixmodule can't be built for lacking chroot(), major(), minor(), makedev() and errnomodule neither. Please undefine _POSIX_C_SOURCES on *BSDs. :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629632&group_id=5470 From noreply@sourceforge.net Mon Oct 28 02:03:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Oct 2002 18:03:10 -0800 Subject: [Patches] [ python-Patches-629637 ] Add k-sets method to random.py Message-ID: Patches item #629637, was opened at 2002-10-27 21:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629637&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Add k-sets method to random.py Initial Comment: random.randset(n, k) returns a k length list of unique integers in the range [0,n). Improves on a Cookbook submission by using the parameters to select between a shuffle algorithm and a dictionary algorithm. I want to add this to the library because it is a simple, robust solution to a general selection problem and because it isn't obvious that two different algorithms are needed to balance speed/space trade-offs. If approved, will add docs and a news item. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629637&group_id=5470 From noreply@sourceforge.net Mon Oct 28 02:31:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Oct 2002 18:31:13 -0800 Subject: [Patches] [ python-Patches-629632 ] Build error on *BSDs with _POSIX_C_SOURC Message-ID: Patches item #629632, was opened at 2002-10-28 10:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629632&group_id=5470 Category: Build Group: Python 2.3 >Status: Deleted Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Build error on *BSDs with _POSIX_C_SOURC Initial Comment: FreeBSD and NetBSD hides non-POSIX functions when _POSIX_C_SOURCE or _POSIX_SOURCE is defined. As a result, posixmodule can't be built for lacking chroot(), major(), minor(), makedev() and errnomodule neither. Please undefine _POSIX_C_SOURCES on *BSDs. :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629632&group_id=5470 From noreply@sourceforge.net Mon Oct 28 12:54:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Oct 2002 04:54:25 -0800 Subject: [Patches] [ python-Patches-629637 ] Add k-sets method to random.py Message-ID: Patches item #629637, was opened at 2002-10-27 21:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629637&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Add k-sets method to random.py Initial Comment: random.randset(n, k) returns a k length list of unique integers in the range [0,n). Improves on a Cookbook submission by using the parameters to select between a shuffle algorithm and a dictionary algorithm. I want to add this to the library because it is a simple, robust solution to a general selection problem and because it isn't obvious that two different algorithms are needed to balance speed/space trade-offs. If approved, will add docs and a news item. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-28 07:54 Message: Logged In: YES user_id=80475 Added full patch with news item and docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629637&group_id=5470 From noreply@sourceforge.net Mon Oct 28 15:46:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Oct 2002 07:46:13 -0800 Subject: [Patches] [ python-Patches-629426 ] autoconf-2.5X mods for configure.in Message-ID: Patches item #629426, was opened at 2002-10-27 09:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629426&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Art Haas (ahaas) Assigned to: Nobody/Anonymous (nobody) Summary: autoconf-2.5X mods for configure.in Initial Comment: Hi. Here's another patch for configure.in that replaces a few more obsolete macros ... AC_CONFIG_HEADER ==> AC_CONFIG_HEADERS AC_ERROR ==> AC_MSG_ERROR There are a couple of uses of AC_MSG_RESULT that had unecessary escaped quotes, so I removed them. These were pointed out when running "autoconf --warnings=all". This patch also adds the AC_HELP_STRING macro in most of the AC_ARG_* macros. This macro is designed to format the output the configure script presents when invoked "configure --help". In adding this macro I've added a few more explicit quotes in some of the AC_ARG_* macros also. The AC_HELP_STRING macro itself though is not quoted (unlike nearly every other macro in autoconf-2.5X) as this is specified by the autoconf docs. A couple of places in the patch have "@<:@" and "@:>@". These are autoconf quadrigraphs that expand to "[' and "]" in the configure script. I used them so the "--help" output would retain the square brackets in places it does currently. ---------------------------------------------------------------------- >Comment By: Art Haas (ahaas) Date: 2002-10-28 09:46 Message: Logged In: YES user_id=629911 My wording was poor with regards to AC_CONFIG_HEADER. The macro itself is defined in the autoconf library file status.m4 as ... # AC_CONFIG_HEADER(HEADER-TO-CREATE ...) # -------------------------------------- # FIXME: Make it obsolete? AC_DEFUN([AC_CONFIG_HEADER], [AC_CONFIG_HEADERS([$1])]) ... so it is just a wrapper around AC_CONFIG_HEADERS. Plus, AC_CONFIG_HEADERS is the documented macro to use. As for the quoting, I've been following the examples listed in the autoconf docs, and in there the arguments are quoted. Having the explicit quotes does add a little bit to the file (sizewise), but I don't think their presence hurts. Using quadrigraphs in the configure templates seems to be the right way to produce "[" and "]" characters in the output. Using the changequote m4 macro is really, really, really discouraged in the autoconf docs, given that there is a section called "Changequote is evil". How about, instead of the output help string looking like ... --with-foo use some value foo [default=yes] ... the characters "<" and ">" are used .... ---with-foo use some value foo The quadrigraphs can then be replaced with angle brackets. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-27 13:33 Message: Logged In: YES user_id=21627 I'm with you for most of these changes. However: - where does it say that AC_CONFIG_HEADER is obsolete? We only have one header. - Please avoid unnecessary quoting. I.e. don't write AC_HELP_STRING([--without-gcc], [never use gcc]), but write AC_HELP(--without-gcc, never use gcc) (Quoting spaced strings is perhaps acceptable; quoting individual words is not) - Those quadrigraphs look terrible. Try using changequote instead (e.g. to <<,>>) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629426&group_id=5470 From noreply@sourceforge.net Mon Oct 28 16:49:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Oct 2002 08:49:03 -0800 Subject: [Patches] [ python-Patches-629426 ] autoconf-2.5X mods for configure.in Message-ID: Patches item #629426, was opened at 2002-10-27 16:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629426&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Art Haas (ahaas) Assigned to: Nobody/Anonymous (nobody) Summary: autoconf-2.5X mods for configure.in Initial Comment: Hi. Here's another patch for configure.in that replaces a few more obsolete macros ... AC_CONFIG_HEADER ==> AC_CONFIG_HEADERS AC_ERROR ==> AC_MSG_ERROR There are a couple of uses of AC_MSG_RESULT that had unecessary escaped quotes, so I removed them. These were pointed out when running "autoconf --warnings=all". This patch also adds the AC_HELP_STRING macro in most of the AC_ARG_* macros. This macro is designed to format the output the configure script presents when invoked "configure --help". In adding this macro I've added a few more explicit quotes in some of the AC_ARG_* macros also. The AC_HELP_STRING macro itself though is not quoted (unlike nearly every other macro in autoconf-2.5X) as this is specified by the autoconf docs. A couple of places in the patch have "@<:@" and "@:>@". These are autoconf quadrigraphs that expand to "[' and "]" in the configure script. I used them so the "--help" output would retain the square brackets in places it does currently. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-28 17:49 Message: Logged In: YES user_id=21627 As for AC_CONFIG_HEADER: I'd prefer it to stay that way until the macro really is deprecated. AC_CONFIG_HEADERS sounds wrong. Re quotes: Please do revise the patch in this respect. Too much punctuation is unpythonic, regardless of how the autoconf manual examples are formulated. Re changequote: Ok, you can have the quadrigraphs; please add a comment before each uses to indicate what they are. Using <> is worse, since [] signals optionality in an established way. ---------------------------------------------------------------------- Comment By: Art Haas (ahaas) Date: 2002-10-28 16:46 Message: Logged In: YES user_id=629911 My wording was poor with regards to AC_CONFIG_HEADER. The macro itself is defined in the autoconf library file status.m4 as ... # AC_CONFIG_HEADER(HEADER-TO-CREATE ...) # -------------------------------------- # FIXME: Make it obsolete? AC_DEFUN([AC_CONFIG_HEADER], [AC_CONFIG_HEADERS([$1])]) ... so it is just a wrapper around AC_CONFIG_HEADERS. Plus, AC_CONFIG_HEADERS is the documented macro to use. As for the quoting, I've been following the examples listed in the autoconf docs, and in there the arguments are quoted. Having the explicit quotes does add a little bit to the file (sizewise), but I don't think their presence hurts. Using quadrigraphs in the configure templates seems to be the right way to produce "[" and "]" characters in the output. Using the changequote m4 macro is really, really, really discouraged in the autoconf docs, given that there is a section called "Changequote is evil". How about, instead of the output help string looking like ... --with-foo use some value foo [default=yes] ... the characters "<" and ">" are used .... ---with-foo use some value foo The quadrigraphs can then be replaced with angle brackets. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-27 20:33 Message: Logged In: YES user_id=21627 I'm with you for most of these changes. However: - where does it say that AC_CONFIG_HEADER is obsolete? We only have one header. - Please avoid unnecessary quoting. I.e. don't write AC_HELP_STRING([--without-gcc], [never use gcc]), but write AC_HELP(--without-gcc, never use gcc) (Quoting spaced strings is perhaps acceptable; quoting individual words is not) - Those quadrigraphs look terrible. Try using changequote instead (e.g. to <<,>>) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629426&group_id=5470 From noreply@sourceforge.net Tue Oct 29 00:37:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Oct 2002 16:37:45 -0800 Subject: [Patches] [ python-Patches-629426 ] autoconf-2.5X mods for configure.in Message-ID: Patches item #629426, was opened at 2002-10-27 09:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629426&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Art Haas (ahaas) Assigned to: Nobody/Anonymous (nobody) Summary: autoconf-2.5X mods for configure.in Initial Comment: Hi. Here's another patch for configure.in that replaces a few more obsolete macros ... AC_CONFIG_HEADER ==> AC_CONFIG_HEADERS AC_ERROR ==> AC_MSG_ERROR There are a couple of uses of AC_MSG_RESULT that had unecessary escaped quotes, so I removed them. These were pointed out when running "autoconf --warnings=all". This patch also adds the AC_HELP_STRING macro in most of the AC_ARG_* macros. This macro is designed to format the output the configure script presents when invoked "configure --help". In adding this macro I've added a few more explicit quotes in some of the AC_ARG_* macros also. The AC_HELP_STRING macro itself though is not quoted (unlike nearly every other macro in autoconf-2.5X) as this is specified by the autoconf docs. A couple of places in the patch have "@<:@" and "@:>@". These are autoconf quadrigraphs that expand to "[' and "]" in the configure script. I used them so the "--help" output would retain the square brackets in places it does currently. ---------------------------------------------------------------------- >Comment By: Art Haas (ahaas) Date: 2002-10-28 18:37 Message: Logged In: YES user_id=629911 Here's an updated version of the patch. I've dropped the AC_CONFIG_HEADER bit, and adjusted the quotes in the AC_HELP_STRING macros. ---------------------------------------------------------------------- Comment By: Art Haas (ahaas) Date: 2002-10-28 18:35 Message: Logged In: YES user_id=629911 Here's the second version of the patch. I think the quoting is more in line with what you want, and I've not included the AC_CONFIG_HEADERS change. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-28 10:49 Message: Logged In: YES user_id=21627 As for AC_CONFIG_HEADER: I'd prefer it to stay that way until the macro really is deprecated. AC_CONFIG_HEADERS sounds wrong. Re quotes: Please do revise the patch in this respect. Too much punctuation is unpythonic, regardless of how the autoconf manual examples are formulated. Re changequote: Ok, you can have the quadrigraphs; please add a comment before each uses to indicate what they are. Using <> is worse, since [] signals optionality in an established way. ---------------------------------------------------------------------- Comment By: Art Haas (ahaas) Date: 2002-10-28 09:46 Message: Logged In: YES user_id=629911 My wording was poor with regards to AC_CONFIG_HEADER. The macro itself is defined in the autoconf library file status.m4 as ... # AC_CONFIG_HEADER(HEADER-TO-CREATE ...) # -------------------------------------- # FIXME: Make it obsolete? AC_DEFUN([AC_CONFIG_HEADER], [AC_CONFIG_HEADERS([$1])]) ... so it is just a wrapper around AC_CONFIG_HEADERS. Plus, AC_CONFIG_HEADERS is the documented macro to use. As for the quoting, I've been following the examples listed in the autoconf docs, and in there the arguments are quoted. Having the explicit quotes does add a little bit to the file (sizewise), but I don't think their presence hurts. Using quadrigraphs in the configure templates seems to be the right way to produce "[" and "]" characters in the output. Using the changequote m4 macro is really, really, really discouraged in the autoconf docs, given that there is a section called "Changequote is evil". How about, instead of the output help string looking like ... --with-foo use some value foo [default=yes] ... the characters "<" and ">" are used .... ---with-foo use some value foo The quadrigraphs can then be replaced with angle brackets. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-27 13:33 Message: Logged In: YES user_id=21627 I'm with you for most of these changes. However: - where does it say that AC_CONFIG_HEADER is obsolete? We only have one header. - Please avoid unnecessary quoting. I.e. don't write AC_HELP_STRING([--without-gcc], [never use gcc]), but write AC_HELP(--without-gcc, never use gcc) (Quoting spaced strings is perhaps acceptable; quoting individual words is not) - Those quadrigraphs look terrible. Try using changequote instead (e.g. to <<,>>) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629426&group_id=5470 From noreply@sourceforge.net Tue Oct 29 00:35:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Oct 2002 16:35:35 -0800 Subject: [Patches] [ python-Patches-629426 ] autoconf-2.5X mods for configure.in Message-ID: Patches item #629426, was opened at 2002-10-27 09:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629426&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Art Haas (ahaas) Assigned to: Nobody/Anonymous (nobody) Summary: autoconf-2.5X mods for configure.in Initial Comment: Hi. Here's another patch for configure.in that replaces a few more obsolete macros ... AC_CONFIG_HEADER ==> AC_CONFIG_HEADERS AC_ERROR ==> AC_MSG_ERROR There are a couple of uses of AC_MSG_RESULT that had unecessary escaped quotes, so I removed them. These were pointed out when running "autoconf --warnings=all". This patch also adds the AC_HELP_STRING macro in most of the AC_ARG_* macros. This macro is designed to format the output the configure script presents when invoked "configure --help". In adding this macro I've added a few more explicit quotes in some of the AC_ARG_* macros also. The AC_HELP_STRING macro itself though is not quoted (unlike nearly every other macro in autoconf-2.5X) as this is specified by the autoconf docs. A couple of places in the patch have "@<:@" and "@:>@". These are autoconf quadrigraphs that expand to "[' and "]" in the configure script. I used them so the "--help" output would retain the square brackets in places it does currently. ---------------------------------------------------------------------- >Comment By: Art Haas (ahaas) Date: 2002-10-28 18:35 Message: Logged In: YES user_id=629911 Here's the second version of the patch. I think the quoting is more in line with what you want, and I've not included the AC_CONFIG_HEADERS change. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-28 10:49 Message: Logged In: YES user_id=21627 As for AC_CONFIG_HEADER: I'd prefer it to stay that way until the macro really is deprecated. AC_CONFIG_HEADERS sounds wrong. Re quotes: Please do revise the patch in this respect. Too much punctuation is unpythonic, regardless of how the autoconf manual examples are formulated. Re changequote: Ok, you can have the quadrigraphs; please add a comment before each uses to indicate what they are. Using <> is worse, since [] signals optionality in an established way. ---------------------------------------------------------------------- Comment By: Art Haas (ahaas) Date: 2002-10-28 09:46 Message: Logged In: YES user_id=629911 My wording was poor with regards to AC_CONFIG_HEADER. The macro itself is defined in the autoconf library file status.m4 as ... # AC_CONFIG_HEADER(HEADER-TO-CREATE ...) # -------------------------------------- # FIXME: Make it obsolete? AC_DEFUN([AC_CONFIG_HEADER], [AC_CONFIG_HEADERS([$1])]) ... so it is just a wrapper around AC_CONFIG_HEADERS. Plus, AC_CONFIG_HEADERS is the documented macro to use. As for the quoting, I've been following the examples listed in the autoconf docs, and in there the arguments are quoted. Having the explicit quotes does add a little bit to the file (sizewise), but I don't think their presence hurts. Using quadrigraphs in the configure templates seems to be the right way to produce "[" and "]" characters in the output. Using the changequote m4 macro is really, really, really discouraged in the autoconf docs, given that there is a section called "Changequote is evil". How about, instead of the output help string looking like ... --with-foo use some value foo [default=yes] ... the characters "<" and ">" are used .... ---with-foo use some value foo The quadrigraphs can then be replaced with angle brackets. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-27 13:33 Message: Logged In: YES user_id=21627 I'm with you for most of these changes. However: - where does it say that AC_CONFIG_HEADER is obsolete? We only have one header. - Please avoid unnecessary quoting. I.e. don't write AC_HELP_STRING([--without-gcc], [never use gcc]), but write AC_HELP(--without-gcc, never use gcc) (Quoting spaced strings is perhaps acceptable; quoting individual words is not) - Those quadrigraphs look terrible. Try using changequote instead (e.g. to <<,>>) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629426&group_id=5470 From noreply@sourceforge.net Tue Oct 29 04:42:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Oct 2002 20:42:18 -0800 Subject: [Patches] [ python-Patches-629637 ] Add a sample selection method to random.py Message-ID: Patches item #629637, was opened at 2002-10-27 21:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629637&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) >Summary: Add a sample selection method to random.py Initial Comment: random.randset(n, k) returns a k length list of unique integers in the range [0,n). Improves on a Cookbook submission by using the parameters to select between a shuffle algorithm and a dictionary algorithm. I want to add this to the library because it is a simple, robust solution to a general selection problem and because it isn't obvious that two different algorithms are needed to balance speed/space trade-offs. If approved, will add docs and a news item. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-28 23:42 Message: Logged In: YES user_id=80475 Renamed to random.sample(n,k) to show that it is used for sampling without replacement. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-28 07:54 Message: Logged In: YES user_id=80475 Added full patch with news item and docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629637&group_id=5470 From noreply@sourceforge.net Tue Oct 29 04:42:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Oct 2002 20:42:55 -0800 Subject: [Patches] [ python-Patches-629637 ] Add a sample selection method to random.py Message-ID: Patches item #629637, was opened at 2002-10-27 21:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629637&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Add a sample selection method to random.py Initial Comment: random.randset(n, k) returns a k length list of unique integers in the range [0,n). Improves on a Cookbook submission by using the parameters to select between a shuffle algorithm and a dictionary algorithm. I want to add this to the library because it is a simple, robust solution to a general selection problem and because it isn't obvious that two different algorithms are needed to balance speed/space trade-offs. If approved, will add docs and a news item. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-28 23:42 Message: Logged In: YES user_id=80475 Renamed to random.sample(n,k) to show that it is used for sampling without replacement. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-28 23:42 Message: Logged In: YES user_id=80475 Renamed to random.sample(n,k) to show that it is used for sampling without replacement. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-28 07:54 Message: Logged In: YES user_id=80475 Added full patch with news item and docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629637&group_id=5470 From noreply@sourceforge.net Tue Oct 29 10:08:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Oct 2002 02:08:25 -0800 Subject: [Patches] [ python-Patches-629426 ] autoconf-2.5X mods for configure.in Message-ID: Patches item #629426, was opened at 2002-10-27 16:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629426&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Art Haas (ahaas) Assigned to: Nobody/Anonymous (nobody) Summary: autoconf-2.5X mods for configure.in Initial Comment: Hi. Here's another patch for configure.in that replaces a few more obsolete macros ... AC_CONFIG_HEADER ==> AC_CONFIG_HEADERS AC_ERROR ==> AC_MSG_ERROR There are a couple of uses of AC_MSG_RESULT that had unecessary escaped quotes, so I removed them. These were pointed out when running "autoconf --warnings=all". This patch also adds the AC_HELP_STRING macro in most of the AC_ARG_* macros. This macro is designed to format the output the configure script presents when invoked "configure --help". In adding this macro I've added a few more explicit quotes in some of the AC_ARG_* macros also. The AC_HELP_STRING macro itself though is not quoted (unlike nearly every other macro in autoconf-2.5X) as this is specified by the autoconf docs. A couple of places in the patch have "@<:@" and "@:>@". These are autoconf quadrigraphs that expand to "[' and "]" in the configure script. I used them so the "--help" output would retain the square brackets in places it does currently. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-29 11:08 Message: Logged In: YES user_id=21627 Thanks for the patch, committed as configure.in 1.361, configure 1.350. ---------------------------------------------------------------------- Comment By: Art Haas (ahaas) Date: 2002-10-29 01:37 Message: Logged In: YES user_id=629911 Here's an updated version of the patch. I've dropped the AC_CONFIG_HEADER bit, and adjusted the quotes in the AC_HELP_STRING macros. ---------------------------------------------------------------------- Comment By: Art Haas (ahaas) Date: 2002-10-29 01:35 Message: Logged In: YES user_id=629911 Here's the second version of the patch. I think the quoting is more in line with what you want, and I've not included the AC_CONFIG_HEADERS change. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-28 17:49 Message: Logged In: YES user_id=21627 As for AC_CONFIG_HEADER: I'd prefer it to stay that way until the macro really is deprecated. AC_CONFIG_HEADERS sounds wrong. Re quotes: Please do revise the patch in this respect. Too much punctuation is unpythonic, regardless of how the autoconf manual examples are formulated. Re changequote: Ok, you can have the quadrigraphs; please add a comment before each uses to indicate what they are. Using <> is worse, since [] signals optionality in an established way. ---------------------------------------------------------------------- Comment By: Art Haas (ahaas) Date: 2002-10-28 16:46 Message: Logged In: YES user_id=629911 My wording was poor with regards to AC_CONFIG_HEADER. The macro itself is defined in the autoconf library file status.m4 as ... # AC_CONFIG_HEADER(HEADER-TO-CREATE ...) # -------------------------------------- # FIXME: Make it obsolete? AC_DEFUN([AC_CONFIG_HEADER], [AC_CONFIG_HEADERS([$1])]) ... so it is just a wrapper around AC_CONFIG_HEADERS. Plus, AC_CONFIG_HEADERS is the documented macro to use. As for the quoting, I've been following the examples listed in the autoconf docs, and in there the arguments are quoted. Having the explicit quotes does add a little bit to the file (sizewise), but I don't think their presence hurts. Using quadrigraphs in the configure templates seems to be the right way to produce "[" and "]" characters in the output. Using the changequote m4 macro is really, really, really discouraged in the autoconf docs, given that there is a section called "Changequote is evil". How about, instead of the output help string looking like ... --with-foo use some value foo [default=yes] ... the characters "<" and ">" are used .... ---with-foo use some value foo The quadrigraphs can then be replaced with angle brackets. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-27 20:33 Message: Logged In: YES user_id=21627 I'm with you for most of these changes. However: - where does it say that AC_CONFIG_HEADER is obsolete? We only have one header. - Please avoid unnecessary quoting. I.e. don't write AC_HELP_STRING([--without-gcc], [never use gcc]), but write AC_HELP(--without-gcc, never use gcc) (Quoting spaced strings is perhaps acceptable; quoting individual words is not) - Those quadrigraphs look terrible. Try using changequote instead (e.g. to <<,>>) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629426&group_id=5470 From noreply@sourceforge.net Tue Oct 29 16:44:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Oct 2002 08:44:59 -0800 Subject: [Patches] [ python-Patches-628208 ] xmlrpclib: Optional 'nil' support Message-ID: Patches item #628208, was opened at 2002-10-24 15:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=628208&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Fredrik Lundh (effbot) Summary: xmlrpclib: Optional 'nil' support Initial Comment: This patch doesn't include documentation or test suite updates yet, and only touches the < The extension is defined at http://ontosys.com/xml-rpc/extensions.html. Outstanding questions: * To generate , an option must be explicitly supplied to dumps(). is always accepted, and it can't be turned off. Is this OK? * Similarly, allow_none is on or off for a ServerProxy; you can't turn it on for just one method. (Seems a reasonable limitation...) * Should the parameter to enable it be named allow_none (Python term) or allow_nil (XML-RPC term)? * When allow_none is false and a None is encountered, this patch raises a ValueError. Is that the right exception, or should it use xmlrpclib.Error? Can anyone suggest a better message for the exception? * The FastMarshaller accelerator would also need to be updated. * Are we ever likely to change the default for allow_none to True? If so, how should we arrange things so we can warn people? ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-10-29 11:44 Message: Logged In: YES user_id=11375 Updated version of the patch: raises TypeError instead of ValueError, and uses Martin's suggested wording; thanks! Now it's up to /F to accept, decline, or request revisions to this patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-24 15:50 Message: Logged In: YES user_id=21627 On the exception: Currently, you get TypeError: cannot marshal objects and TypeError seems to be the right thing. The message might read cannot marshal None unless allow_none is enabled On allowing None by default: I'd assume that you would want to disable None only for "strictly-conforming" operation, so I'd expect to see an option strict (which then defaults to False). I don't know in what other ways we'd reasonably deviate from the spec. If that ever happens, I don't think a transitional warning is needed: existing applications continue to work. In general, in cases that produce an exception now, we don't need a transition procedure. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=628208&group_id=5470 From noreply@sourceforge.net Tue Oct 29 18:08:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Oct 2002 10:08:19 -0800 Subject: [Patches] [ python-Patches-630622 ] docstrings in _codecs Message-ID: Patches item #630622, was opened at 2002-10-29 19:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=630622&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: docstrings in _codecs Initial Comment: This patch adds docstrings to the four function register, lookup, register_error and lookup_error in Modules/_codecsmodule.c. Is adding docstrings to the other *_decode/*_encode functions is worth the effort? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=630622&group_id=5470 From noreply@sourceforge.net Wed Oct 30 01:35:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Oct 2002 17:35:45 -0800 Subject: [Patches] [ python-Patches-630829 ] telnetlib don't block on IAC Message-ID: Patches item #630829, was opened at 2002-10-30 01:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=630829&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ha Shao (hashao) Assigned to: Nobody/Anonymous (nobody) Summary: telnetlib don't block on IAC Initial Comment: Use a IAC buffer to make IAC commands not block. Also call callback on command other than WILL/WONT/DO/DONT. People still want to handle other commands. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=630829&group_id=5470 From noreply@sourceforge.net Wed Oct 30 13:57:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Oct 2002 05:57:12 -0800 Subject: [Patches] [ python-Patches-629637 ] Add a sample selection method to random.py Message-ID: Patches item #629637, was opened at 2002-10-27 21:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629637&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Tim Peters (tim_one) Summary: Add a sample selection method to random.py Initial Comment: random.randset(n, k) returns a k length list of unique integers in the range [0,n). Improves on a Cookbook submission by using the parameters to select between a shuffle algorithm and a dictionary algorithm. I want to add this to the library because it is a simple, robust solution to a general selection problem and because it isn't obvious that two different algorithms are needed to balance speed/space trade-offs. If approved, will add docs and a news item. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-28 23:42 Message: Logged In: YES user_id=80475 Renamed to random.sample(n,k) to show that it is used for sampling without replacement. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-28 23:42 Message: Logged In: YES user_id=80475 Renamed to random.sample(n,k) to show that it is used for sampling without replacement. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-28 07:54 Message: Logged In: YES user_id=80475 Added full patch with news item and docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629637&group_id=5470 From noreply@sourceforge.net Wed Oct 30 22:06:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Oct 2002 14:06:14 -0800 Subject: [Patches] [ python-Patches-631276 ] Exceptions raised by line trace function Message-ID: Patches item #631276, was opened at 2002-10-30 22:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=631276&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richie Hindle (richiehindle) Assigned to: Nobody/Anonymous (nobody) Summary: Exceptions raised by line trace function Initial Comment: Exceptions raised by line trace functions are not handled. I'm running the latest 2.3a0 (as of 30th October 2002). When a trace function called with an event of 'line' raises an exception, that exception is ignored by maybe_call_line_trace. This means that program never sees the exception, and that the next genuine exception to be raised gets muddled up with the one raised by the trace function. See the attached script for a demo. The bug (as far as I can tell) is that maybe_call_line_trace is ignoring the return value of call_trace. This patch makes maybe_call_line_trace pass that return value back to eval_frame, which then sets why to WHY_EXCEPTION and jumps to on_error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=631276&group_id=5470 From noreply@sourceforge.net Thu Oct 31 04:17:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Oct 2002 20:17:35 -0800 Subject: [Patches] [ python-Patches-630829 ] telnetlib.py: don't block on IAC and enhancement Message-ID: Patches item #630829, was opened at 2002-10-30 01:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=630829&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Ha Shao (hashao) Assigned to: Nobody/Anonymous (nobody) >Summary: telnetlib.py: don't block on IAC and enhancement Initial Comment: Use a IAC buffer to make IAC commands not block. Also call callback on command other than WILL/WONT/DO/DONT. People still want to handle other commands. ---------------------------------------------------------------------- >Comment By: Ha Shao (hashao) Date: 2002-10-31 04:17 Message: Logged In: YES user_id=8717 A new patch also handle IAC SB ... IAC SE data fetchming for fully handling the telnet protocol. No option will use chr(0) instead of 256. protocol handler should know if a command has option or not, anyway. Supercede the last patch. Please commit. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=630829&group_id=5470 From noreply@sourceforge.net Thu Oct 31 07:29:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Oct 2002 23:29:54 -0800 Subject: [Patches] [ python-Patches-629637 ] Add a sample selection method to random.py Message-ID: Patches item #629637, was opened at 2002-10-27 21:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629637&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Tim Peters (tim_one) Summary: Add a sample selection method to random.py Initial Comment: random.randset(n, k) returns a k length list of unique integers in the range [0,n). Improves on a Cookbook submission by using the parameters to select between a shuffle algorithm and a dictionary algorithm. I want to add this to the library because it is a simple, robust solution to a general selection problem and because it isn't obvious that two different algorithms are needed to balance speed/space trade-offs. If approved, will add docs and a news item. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-31 02:29 Message: Logged In: YES user_id=80475 Added new version with local variable optimization and with the dictionary results returned in selection order. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-28 23:42 Message: Logged In: YES user_id=80475 Renamed to random.sample(n,k) to show that it is used for sampling without replacement. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-28 23:42 Message: Logged In: YES user_id=80475 Renamed to random.sample(n,k) to show that it is used for sampling without replacement. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-28 07:54 Message: Logged In: YES user_id=80475 Added full patch with news item and docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=629637&group_id=5470 From noreply@sourceforge.net Thu Oct 31 10:38:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Oct 2002 02:38:38 -0800 Subject: [Patches] [ python-Patches-631276 ] Exceptions raised by line trace function Message-ID: Patches item #631276, was opened at 2002-10-30 22:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=631276&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richie Hindle (richiehindle) >Assigned to: Michael Hudson (mwh) Summary: Exceptions raised by line trace function Initial Comment: Exceptions raised by line trace functions are not handled. I'm running the latest 2.3a0 (as of 30th October 2002). When a trace function called with an event of 'line' raises an exception, that exception is ignored by maybe_call_line_trace. This means that program never sees the exception, and that the next genuine exception to be raised gets muddled up with the one raised by the trace function. See the attached script for a demo. The bug (as far as I can tell) is that maybe_call_line_trace is ignoring the return value of call_trace. This patch makes maybe_call_line_trace pass that return value back to eval_frame, which then sets why to WHY_EXCEPTION and jumps to on_error. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-10-31 10:38 Message: Logged In: YES user_id=6656 Blame for this one is easy to find... Patch looks OK. Could I ask you to munge the test into a patch to test_trace? Otherwise I'll do it, but maybe not today. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=631276&group_id=5470 From noreply@sourceforge.net Thu Oct 31 13:07:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Oct 2002 05:07:10 -0800 Subject: [Patches] [ python-Patches-630622 ] docstrings in _codecs Message-ID: Patches item #630622, was opened at 2002-10-29 19:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=630622&group_id=5470 Category: Core (C code) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Walter Dörwald (doerwalter) Summary: docstrings in _codecs Initial Comment: This patch adds docstrings to the four function register, lookup, register_error and lookup_error in Modules/_codecsmodule.c. Is adding docstrings to the other *_decode/*_encode functions is worth the effort? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-31 14:07 Message: Logged In: YES user_id=21627 The patch looks fine, please apply it. I would leave the specific encoding functions undocumented - their name implies what they do, and they are not meant for direct usage, anyway. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=630622&group_id=5470 From noreply@sourceforge.net Thu Oct 31 13:39:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Oct 2002 05:39:25 -0800 Subject: [Patches] [ python-Patches-630622 ] docstrings in _codecs Message-ID: Patches item #630622, was opened at 2002-10-29 19:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=630622&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Walter Dörwald (doerwalter) Summary: docstrings in _codecs Initial Comment: This patch adds docstrings to the four function register, lookup, register_error and lookup_error in Modules/_codecsmodule.c. Is adding docstrings to the other *_decode/*_encode functions is worth the effort? ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-10-31 14:39 Message: Logged In: YES user_id=89016 Checked in as Modules/_codecsmodule.c 2.16 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-31 14:07 Message: Logged In: YES user_id=21627 The patch looks fine, please apply it. I would leave the specific encoding functions undocumented - their name implies what they do, and they are not meant for direct usage, anyway. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=630622&group_id=5470 From noreply@sourceforge.net Thu Oct 31 14:38:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Oct 2002 06:38:18 -0800 Subject: [Patches] [ python-Patches-631276 ] Exceptions raised by line trace function Message-ID: Patches item #631276, was opened at 2002-10-30 22:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=631276&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richie Hindle (richiehindle) Assigned to: Michael Hudson (mwh) Summary: Exceptions raised by line trace function Initial Comment: Exceptions raised by line trace functions are not handled. I'm running the latest 2.3a0 (as of 30th October 2002). When a trace function called with an event of 'line' raises an exception, that exception is ignored by maybe_call_line_trace. This means that program never sees the exception, and that the next genuine exception to be raised gets muddled up with the one raised by the trace function. See the attached script for a demo. The bug (as far as I can tell) is that maybe_call_line_trace is ignoring the return value of call_trace. This patch makes maybe_call_line_trace pass that return value back to eval_frame, which then sets why to WHY_EXCEPTION and jumps to on_error. ---------------------------------------------------------------------- >Comment By: Richie Hindle (richiehindle) Date: 2002-10-31 14:38 Message: Logged In: YES user_id=85414 Will do, later today. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-31 10:38 Message: Logged In: YES user_id=6656 Blame for this one is easy to find... Patch looks OK. Could I ask you to munge the test into a patch to test_trace? Otherwise I'll do it, but maybe not today. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=631276&group_id=5470 From noreply@sourceforge.net Thu Oct 31 17:46:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Oct 2002 09:46:47 -0800 Subject: [Patches] [ python-Patches-631678 ] New pdb command "pp" Message-ID: Patches item #631678, was opened at 2002-10-31 12:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=631678&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Tim Peters (tim_one) Summary: New pdb command "pp" Initial Comment: I often find that I want to pretty print values in pdb. This patch adds a "pp" command, which is much like "p" except it pretty prints the value. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=631678&group_id=5470 From noreply@sourceforge.net Thu Oct 31 21:39:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Oct 2002 13:39:02 -0800 Subject: [Patches] [ python-Patches-631276 ] Exceptions raised by line trace function Message-ID: Patches item #631276, was opened at 2002-10-30 22:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=631276&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richie Hindle (richiehindle) Assigned to: Michael Hudson (mwh) Summary: Exceptions raised by line trace function Initial Comment: Exceptions raised by line trace functions are not handled. I'm running the latest 2.3a0 (as of 30th October 2002). When a trace function called with an event of 'line' raises an exception, that exception is ignored by maybe_call_line_trace. This means that program never sees the exception, and that the next genuine exception to be raised gets muddled up with the one raised by the trace function. See the attached script for a demo. The bug (as far as I can tell) is that maybe_call_line_trace is ignoring the return value of call_trace. This patch makes maybe_call_line_trace pass that return value back to eval_frame, which then sets why to WHY_EXCEPTION and jumps to on_error. ---------------------------------------------------------------------- >Comment By: Richie Hindle (richiehindle) Date: 2002-10-31 21:39 Message: Logged In: YES user_id=85414 Here's the patch to test_trace.py. RaisingTraceFuncTestCase now tests each of the four trace events independently. Note that this doesn't show up the problem of the lost exception cropping up when another exception is raised - use the trace_exception_bug.py script if you want to see that. ---------------------------------------------------------------------- Comment By: Richie Hindle (richiehindle) Date: 2002-10-31 14:38 Message: Logged In: YES user_id=85414 Will do, later today. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-31 10:38 Message: Logged In: YES user_id=6656 Blame for this one is easy to find... Patch looks OK. Could I ask you to munge the test into a patch to test_trace? Otherwise I'll do it, but maybe not today. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=631276&group_id=5470 From noreply@sourceforge.net Thu Oct 31 22:13:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Oct 2002 14:13:50 -0800 Subject: [Patches] [ python-Patches-590377 ] db4 include not found Message-ID: Patches item #590377, was opened at 2002-08-02 21:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: Invalid Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: db4 include not found Initial Comment: setup.py looks for the db4 library in /usr/lib, but doesn't look for the header in /usr/include (as you find it on Debian unstable) ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2002-10-31 22:13 Message: Logged In: YES user_id=60903 two possibilities come to mind: dpkg -S /usr/include/db.h prints: libdb4.0-dev: /usr/include/db.h (or libdb3-dev, if the libdb3-dev package is installed). Note that the installation of a libdb-dev package is not required, so this command may return with an error. I'm pretty sure, that dpkg only exists on Debian systems ;-) or else test for the existance of the file /etc/debian_version first. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-27 15:46 Message: Logged In: YES user_id=44345 It's clear we can't blindly add '/usr/include' to db_try_this['db4']['incdirs'] and 'db' to db_try_this['db4']['libs']. Is there some way to unambiguously detect from setup.py that Python is being built on a Debian system and that we are not dealing with an installation of db1 (which I still refuse to enable without manual intervention)? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-27 15:12 Message: Logged In: YES user_id=21627 /usr/include/db.h is not a symlink; it is the file itself. You cannot have multiple bsddb development packages (libdbX-dev) installed, because they conflict with each other. /usr/lib/libdb.so exists and is a symlink to the installed shared library. The file in question isn't actually db.h (for current bsddbmodule.c), but db_185.h, of course. As for base+patch: Sure, Debian already uses such a patch. Matthias is the Debian maintainer of Python, and asks us (as upstream) to include his patch. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-27 14:39 Message: Logged In: YES user_id=44345 Is /usr/include/db.h a symlink to some other file on Debian which is version-specific? If so, I'd be happy to add that directory to the list searched. How does Debian structure its directories to allow multiple versions of Berkeley db to be installed simultaneously? If /usr/include/db.h is the location of the include file, is /usr/lib/libdb.{so,a} the location of the library? The original (db1) versions of Berkeley DB generally had db.h in /usr/include. This version is, unfortunately, both broken and still in use. Other vendors allow multiple versions of the library to be installed, and use a version-specific directory naming scheme to keep things sorted out. Debian could do the same. No matter how strongly you believe /usr/include should be searched, I'm not going to add it by default and risk the chance that other peoples' installs break (silently) as a result. Please read the comments related to db1 in setup.py. (Search for bsddb.) Final thought here... Doesn't Debian have and base+patch sort of system? To install on Debian, all that would need to be done is develop a Debian-specific patch which adds /usr/include to the incdirs key and something like 'db' to the libs key in the db4 section. Skip ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-21 22:11 Message: Logged In: YES user_id=21627 As a bug report, I would close this as "Won't fix", pointing you to the option of not using setup.py, but compiling the module through Modules/Setup. I'd prefer to get a patch, but that should be one that works on all systems. This one breaks on systems where /usr/include/db.h is not a bsddb 4 header file. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-21 21:54 Message: Logged In: YES user_id=60903 > - Doesn't it cause -I/usr/include be added to the > compilation statement? yes, that's not correct > - Why is that done for db4 and not db3? On Debian only one libdb-dev package can be installed at build time. I assure with the build dependencies that I get the correct one. > - How can we know what bsddb version /usr/include/db.h > belongs to? Guessing that it is db4 is error-prone, so it > might be, in fact, better not to find that file. maybe grep for DB_VERSION_MAJOR in the file? I admit, this issue should be a bug report, not a patch ... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-21 21:42 Message: Logged In: YES user_id=21627 Ok, I admit that the patch might be needed; I think it is quite incorrect, though: - Doesn't it cause -I/usr/include be added to the compilation statement? - Why is that done for db4 and not db3? - How can we know what bsddb version /usr/include/db.h belongs to? Guessing that it is db4 is error-prone, so it might be, in fact, better not to find that file. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-21 21:14 Message: Logged In: YES user_id=60903 Martin, you're closing reports very quickly ;-) What makes you think the problem is solved? The code doesn't search /usr/include for db.h. Updated patch included. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 13:06 Message: Logged In: YES user_id=21627 The patch is out-of-date, and appears to be unnecessary. I'm rejecting it - if you still think something needs to be done, please submit a new patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470 From noreply@sourceforge.net Thu Oct 31 22:24:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Oct 2002 14:24:27 -0800 Subject: [Patches] [ python-Patches-590377 ] db4 include not found Message-ID: Patches item #590377, was opened at 2002-08-02 16:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: Invalid Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: db4 include not found Initial Comment: setup.py looks for the db4 library in /usr/lib, but doesn't look for the header in /usr/include (as you find it on Debian unstable) ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-10-31 16:24 Message: Logged In: YES user_id=44345 I was thinking more along the lines of a file we could look for. For example, on my Mandrake systems I have /etc/mandrake-release. I suspect that pretty much rules out other Linux dialects (though what if someone converts to another version but doesn't format their disks?). Testing the presence of dpkg isn't sufficient either. Other systems can use it. In fact, I have dpkg on my MacOSX system as a side-effect of being a fink user (http://fink.sf.net/). ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-31 16:13 Message: Logged In: YES user_id=60903 two possibilities come to mind: dpkg -S /usr/include/db.h prints: libdb4.0-dev: /usr/include/db.h (or libdb3-dev, if the libdb3-dev package is installed). Note that the installation of a libdb-dev package is not required, so this command may return with an error. I'm pretty sure, that dpkg only exists on Debian systems ;-) or else test for the existance of the file /etc/debian_version first. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-27 09:46 Message: Logged In: YES user_id=44345 It's clear we can't blindly add '/usr/include' to db_try_this['db4']['incdirs'] and 'db' to db_try_this['db4']['libs']. Is there some way to unambiguously detect from setup.py that Python is being built on a Debian system and that we are not dealing with an installation of db1 (which I still refuse to enable without manual intervention)? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-27 09:12 Message: Logged In: YES user_id=21627 /usr/include/db.h is not a symlink; it is the file itself. You cannot have multiple bsddb development packages (libdbX-dev) installed, because they conflict with each other. /usr/lib/libdb.so exists and is a symlink to the installed shared library. The file in question isn't actually db.h (for current bsddbmodule.c), but db_185.h, of course. As for base+patch: Sure, Debian already uses such a patch. Matthias is the Debian maintainer of Python, and asks us (as upstream) to include his patch. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-10-27 08:39 Message: Logged In: YES user_id=44345 Is /usr/include/db.h a symlink to some other file on Debian which is version-specific? If so, I'd be happy to add that directory to the list searched. How does Debian structure its directories to allow multiple versions of Berkeley db to be installed simultaneously? If /usr/include/db.h is the location of the include file, is /usr/lib/libdb.{so,a} the location of the library? The original (db1) versions of Berkeley DB generally had db.h in /usr/include. This version is, unfortunately, both broken and still in use. Other vendors allow multiple versions of the library to be installed, and use a version-specific directory naming scheme to keep things sorted out. Debian could do the same. No matter how strongly you believe /usr/include should be searched, I'm not going to add it by default and risk the chance that other peoples' installs break (silently) as a result. Please read the comments related to db1 in setup.py. (Search for bsddb.) Final thought here... Doesn't Debian have and base+patch sort of system? To install on Debian, all that would need to be done is develop a Debian-specific patch which adds /usr/include to the incdirs key and something like 'db' to the libs key in the db4 section. Skip ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-21 17:11 Message: Logged In: YES user_id=21627 As a bug report, I would close this as "Won't fix", pointing you to the option of not using setup.py, but compiling the module through Modules/Setup. I'd prefer to get a patch, but that should be one that works on all systems. This one breaks on systems where /usr/include/db.h is not a bsddb 4 header file. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-21 16:54 Message: Logged In: YES user_id=60903 > - Doesn't it cause -I/usr/include be added to the > compilation statement? yes, that's not correct > - Why is that done for db4 and not db3? On Debian only one libdb-dev package can be installed at build time. I assure with the build dependencies that I get the correct one. > - How can we know what bsddb version /usr/include/db.h > belongs to? Guessing that it is db4 is error-prone, so it > might be, in fact, better not to find that file. maybe grep for DB_VERSION_MAJOR in the file? I admit, this issue should be a bug report, not a patch ... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-21 16:42 Message: Logged In: YES user_id=21627 Ok, I admit that the patch might be needed; I think it is quite incorrect, though: - Doesn't it cause -I/usr/include be added to the compilation statement? - Why is that done for db4 and not db3? - How can we know what bsddb version /usr/include/db.h belongs to? Guessing that it is db4 is error-prone, so it might be, in fact, better not to find that file. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-21 16:14 Message: Logged In: YES user_id=60903 Martin, you're closing reports very quickly ;-) What makes you think the problem is solved? The code doesn't search /usr/include for db.h. Updated patch included. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 08:06 Message: Logged In: YES user_id=21627 The patch is out-of-date, and appears to be unnecessary. I'm rejecting it - if you still think something needs to be done, please submit a new patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590377&group_id=5470 From noreply@sourceforge.net Thu Oct 31 23:46:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Oct 2002 15:46:02 -0800 Subject: [Patches] [ python-Patches-473586 ] SimpleXMLRPCServer - fixes and CGI Message-ID: Patches item #473586, was opened at 2001-10-22 00:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=473586&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Fredrik Lundh (effbot) Summary: SimpleXMLRPCServer - fixes and CGI Initial Comment: Changes: o treats xmlrpclib.Fault's correctly (no longer absorbes them as generic exceptions) o changed failed marshal to generate a useful Fault instead of an internal server error o adds a new class to make writing XML-RPC functions embedded in other servers, using CGI, easier (tested with APACHE) o to support the above, added a new dispatch helper class SimpleXMLRPCDispatcher ---------------------------------------------------------------------- >Comment By: Brian Quinlan (bquinlan) Date: 2002-10-31 15:46 Message: Logged In: YES user_id=108973 Martin, I don't have a lot of bandwidth right now but I'll try to do that soon. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-26 08:23 Message: Logged In: YES user_id=21627 Brian, the patch looks good to me. However, can you please also supply patches to Doc/lib/libsimplexmlrpc? ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2002-03-18 11:41 Message: Logged In: YES user_id=108973 OK, I fixed the backwards compatibility problem. Also added: o support for the XML-RPC introspection methods system.listMethods and system.methodHelp o support for the XML-RPC boxcaring method system.multicall ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-12-04 11:51 Message: Logged In: YES user_id=108973 Please do not accept this patch past 2.2 release; there are so non-backwards compatible changes that need to be though through. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-23 11:02 Message: Logged In: YES user_id=108973 - a few extra comments - moved a xmlrpclib.loads() inside an exception handler so an XML-RPC fault is generated for malformed requests ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-22 11:59 Message: Logged In: YES user_id=108973 The advantage of the entire patch being accepted before 2.2 is that there is an API change and, once 2.2 is release, we will probably have to make a bit of an attempt to maintain backwards compatibility. If this patch is too high-risk for 2.2 then I can certainly design a bug-fix patch for 2.2 and submit a new patch for 2.3 (that is API compatible with 2.2). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-22 11:43 Message: Logged In: YES user_id=21627 Brian, please note that Python 2.2b1 has been released, so no new features are acceptable until 2.2. So unless Fredrik Lundh wants to accept your entire patch, I think it has little chance to get integrated for the next few months. If you want pieces of it accepted, I'd recommend to split it into bug fixes and new features; bug fixes are still acceptable. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-22 11:27 Message: Logged In: YES user_id=108973 I just can't stop mucking with it. This time there are only documentation changes. I should also have pointed out that this patch changes the mechanism for overriding the dispatch mechanism: you used to subclass the request handler, now you subclass the server. I believe that this change is correct because the server actually has the required state information to do the dispatching. ---------------------------------------------------------------------- Comment By: Brian Quinlan (bquinlan) Date: 2001-10-22 00:35 Message: Logged In: YES user_id=108973 Changed a name to fit other naming conventions ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=473586&group_id=5470