From noreply@sourceforge.net Fri Sep 1 01:28:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 17:28:36 -0700 Subject: [Patches] [Patch #101346] print warning if exception occurs in GC Message-ID: <200009010028.RAA19527@delerium.i.sourceforge.net> Patch #101346 has been updated. Project: Category: core (C code) Status: Open Summary: print warning if exception occurs in GC Follow-Ups: Date: 2000-Aug-29 12:29 By: jhylton Comment: This appears to fix #110915 on Linux. It's not entirely clear that I've but the fetch/restore in the right place, but I think that all collections begin with collect_generations. ------------------------------------------------------- Date: 2000-Aug-29 13:34 By: jhylton Comment: Get rid of the PyErr_Clear that was causing problems and make sure we always restore the exception state before leaving collect_generations. Further, copy code from __del__ to print a message on stderr if the garbage collector did raise an exception. It seems dangerous to ignore one completely, but it's not clear how to recover. If the latter change makes any sense, we'll need to extract the two copies of the code (from classobject.c and gcmodule.c) and put a helper function in errors.c ------------------------------------------------------- Date: 2000-Aug-30 06:40 By: marangoz Comment: Hm. The offending PyErr_Clear should definitely be removed. Not sure that surrounding the collection process with err fetch/restore is a good idea though. The collector could trigger __del__ methods which in turn could set exceptions. The GC code itself should be absolutely transparent w.r.t. exceptions and should propagate them if they're raised elsewhere. So, what needs to be done here is: - remove PyErrClear - use PySys_WriteStderr for debugging. The whole "output" stuff in gcmodule.c should be zapped, because it's a suboptimal and incomplete PySys_WriteStderr. The latter takes care to fetch/restore exceptions when printing the output. PS: now that this is assigned to me, can I upload another patch over this one for review? ------------------------------------------------------- Date: 2000-Aug-30 12:48 By: gvanrossum Comment: We agree with Vladimir. You can't upload a new version to this patch, but you can submit it as a new patch. We still want to check for spurious exceptions in the GC code and turn them into fatal errors, because they shouldn't happen and we want to make sure they don't. ------------------------------------------------------- Date: 2000-Aug-31 14:44 By: jhylton Comment: This is a paranoid safety measure. The GC should not raise any exceptions, and we don't think it does. But just in case, print a message to stderr if an exception does occur. Then raise a fatal error. ------------------------------------------------------- Date: 2000-Aug-31 15:01 By: bwarsaw Comment: Summary: - I'd call the factored out C function PyError_WriteUnraisable() - not sure gcmodule.c's `unhandled' needs to be a static, but perhaps you're worried about unexpected memory errors? - if you keep this variable, maybe call it gcerror. Other than that +1 ------------------------------------------------------- Date: 2000-Aug-31 17:28 By: jhylton Comment: About the static unhandled: Yes. I'm worried because an unexpected exception has already occurred. If another occurs while creating the Python string object, it will hide the first exception. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101346&group_id=5470 From noreply@sourceforge.net Fri Sep 1 01:56:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 17:56:37 -0700 Subject: [Patches] [Patch #101346] print warning if exception occurs in GC Message-ID: <200009010056.RAA25990@bush.i.sourceforge.net> Patch #101346 has been updated. Project: Category: core (C code) Status: Open Summary: print warning if exception occurs in GC Follow-Ups: Date: 2000-Aug-29 12:29 By: jhylton Comment: This appears to fix #110915 on Linux. It's not entirely clear that I've but the fetch/restore in the right place, but I think that all collections begin with collect_generations. ------------------------------------------------------- Date: 2000-Aug-29 13:34 By: jhylton Comment: Get rid of the PyErr_Clear that was causing problems and make sure we always restore the exception state before leaving collect_generations. Further, copy code from __del__ to print a message on stderr if the garbage collector did raise an exception. It seems dangerous to ignore one completely, but it's not clear how to recover. If the latter change makes any sense, we'll need to extract the two copies of the code (from classobject.c and gcmodule.c) and put a helper function in errors.c ------------------------------------------------------- Date: 2000-Aug-30 06:40 By: marangoz Comment: Hm. The offending PyErr_Clear should definitely be removed. Not sure that surrounding the collection process with err fetch/restore is a good idea though. The collector could trigger __del__ methods which in turn could set exceptions. The GC code itself should be absolutely transparent w.r.t. exceptions and should propagate them if they're raised elsewhere. So, what needs to be done here is: - remove PyErrClear - use PySys_WriteStderr for debugging. The whole "output" stuff in gcmodule.c should be zapped, because it's a suboptimal and incomplete PySys_WriteStderr. The latter takes care to fetch/restore exceptions when printing the output. PS: now that this is assigned to me, can I upload another patch over this one for review? ------------------------------------------------------- Date: 2000-Aug-30 12:48 By: gvanrossum Comment: We agree with Vladimir. You can't upload a new version to this patch, but you can submit it as a new patch. We still want to check for spurious exceptions in the GC code and turn them into fatal errors, because they shouldn't happen and we want to make sure they don't. ------------------------------------------------------- Date: 2000-Aug-31 14:44 By: jhylton Comment: This is a paranoid safety measure. The GC should not raise any exceptions, and we don't think it does. But just in case, print a message to stderr if an exception does occur. Then raise a fatal error. ------------------------------------------------------- Date: 2000-Aug-31 15:01 By: bwarsaw Comment: Summary: - I'd call the factored out C function PyError_WriteUnraisable() - not sure gcmodule.c's `unhandled' needs to be a static, but perhaps you're worried about unexpected memory errors? - if you keep this variable, maybe call it gcerror. Other than that +1 ------------------------------------------------------- Date: 2000-Aug-31 17:28 By: jhylton Comment: About the static unhandled: Yes. I'm worried because an unexpected exception has already occurred. If another occurs while creating the Python string object, it will hide the first exception. ------------------------------------------------------- Date: 2000-Aug-31 17:56 By: jhylton Comment: Address Barry's comments ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101346&group_id=5470 From noreply@sourceforge.net Fri Sep 1 01:59:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 17:59:37 -0700 Subject: [Patches] [Patch #101346] print warning if exception occurs in GC Message-ID: <200009010059.RAA26128@bush.i.sourceforge.net> Patch #101346 has been updated. Project: Category: core (C code) Status: Open Summary: print warning if exception occurs in GC Follow-Ups: Date: 2000-Aug-29 12:29 By: jhylton Comment: This appears to fix #110915 on Linux. It's not entirely clear that I've but the fetch/restore in the right place, but I think that all collections begin with collect_generations. ------------------------------------------------------- Date: 2000-Aug-29 13:34 By: jhylton Comment: Get rid of the PyErr_Clear that was causing problems and make sure we always restore the exception state before leaving collect_generations. Further, copy code from __del__ to print a message on stderr if the garbage collector did raise an exception. It seems dangerous to ignore one completely, but it's not clear how to recover. If the latter change makes any sense, we'll need to extract the two copies of the code (from classobject.c and gcmodule.c) and put a helper function in errors.c ------------------------------------------------------- Date: 2000-Aug-30 06:40 By: marangoz Comment: Hm. The offending PyErr_Clear should definitely be removed. Not sure that surrounding the collection process with err fetch/restore is a good idea though. The collector could trigger __del__ methods which in turn could set exceptions. The GC code itself should be absolutely transparent w.r.t. exceptions and should propagate them if they're raised elsewhere. So, what needs to be done here is: - remove PyErrClear - use PySys_WriteStderr for debugging. The whole "output" stuff in gcmodule.c should be zapped, because it's a suboptimal and incomplete PySys_WriteStderr. The latter takes care to fetch/restore exceptions when printing the output. PS: now that this is assigned to me, can I upload another patch over this one for review? ------------------------------------------------------- Date: 2000-Aug-30 12:48 By: gvanrossum Comment: We agree with Vladimir. You can't upload a new version to this patch, but you can submit it as a new patch. We still want to check for spurious exceptions in the GC code and turn them into fatal errors, because they shouldn't happen and we want to make sure they don't. ------------------------------------------------------- Date: 2000-Aug-31 14:44 By: jhylton Comment: This is a paranoid safety measure. The GC should not raise any exceptions, and we don't think it does. But just in case, print a message to stderr if an exception does occur. Then raise a fatal error. ------------------------------------------------------- Date: 2000-Aug-31 15:01 By: bwarsaw Comment: Summary: - I'd call the factored out C function PyError_WriteUnraisable() - not sure gcmodule.c's `unhandled' needs to be a static, but perhaps you're worried about unexpected memory errors? - if you keep this variable, maybe call it gcerror. Other than that +1 ------------------------------------------------------- Date: 2000-Aug-31 17:28 By: jhylton Comment: About the static unhandled: Yes. I'm worried because an unexpected exception has already occurred. If another occurs while creating the Python string object, it will hide the first exception. ------------------------------------------------------- Date: 2000-Aug-31 17:56 By: jhylton Comment: Address Barry's comments ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101346&group_id=5470 From noreply@sourceforge.net Fri Sep 1 03:02:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 19:02:49 -0700 Subject: [Patches] [Patch #101346] print warning if exception occurs in GC Message-ID: <200009010202.TAA28233@bush.i.sourceforge.net> Patch #101346 has been updated. Project: Category: core (C code) Status: Accepted Summary: print warning if exception occurs in GC Follow-Ups: Date: 2000-Aug-29 12:29 By: jhylton Comment: This appears to fix #110915 on Linux. It's not entirely clear that I've but the fetch/restore in the right place, but I think that all collections begin with collect_generations. ------------------------------------------------------- Date: 2000-Aug-29 13:34 By: jhylton Comment: Get rid of the PyErr_Clear that was causing problems and make sure we always restore the exception state before leaving collect_generations. Further, copy code from __del__ to print a message on stderr if the garbage collector did raise an exception. It seems dangerous to ignore one completely, but it's not clear how to recover. If the latter change makes any sense, we'll need to extract the two copies of the code (from classobject.c and gcmodule.c) and put a helper function in errors.c ------------------------------------------------------- Date: 2000-Aug-30 06:40 By: marangoz Comment: Hm. The offending PyErr_Clear should definitely be removed. Not sure that surrounding the collection process with err fetch/restore is a good idea though. The collector could trigger __del__ methods which in turn could set exceptions. The GC code itself should be absolutely transparent w.r.t. exceptions and should propagate them if they're raised elsewhere. So, what needs to be done here is: - remove PyErrClear - use PySys_WriteStderr for debugging. The whole "output" stuff in gcmodule.c should be zapped, because it's a suboptimal and incomplete PySys_WriteStderr. The latter takes care to fetch/restore exceptions when printing the output. PS: now that this is assigned to me, can I upload another patch over this one for review? ------------------------------------------------------- Date: 2000-Aug-30 12:48 By: gvanrossum Comment: We agree with Vladimir. You can't upload a new version to this patch, but you can submit it as a new patch. We still want to check for spurious exceptions in the GC code and turn them into fatal errors, because they shouldn't happen and we want to make sure they don't. ------------------------------------------------------- Date: 2000-Aug-31 14:44 By: jhylton Comment: This is a paranoid safety measure. The GC should not raise any exceptions, and we don't think it does. But just in case, print a message to stderr if an exception does occur. Then raise a fatal error. ------------------------------------------------------- Date: 2000-Aug-31 15:01 By: bwarsaw Comment: Summary: - I'd call the factored out C function PyError_WriteUnraisable() - not sure gcmodule.c's `unhandled' needs to be a static, but perhaps you're worried about unexpected memory errors? - if you keep this variable, maybe call it gcerror. Other than that +1 ------------------------------------------------------- Date: 2000-Aug-31 17:28 By: jhylton Comment: About the static unhandled: Yes. I'm worried because an unexpected exception has already occurred. If another occurs while creating the Python string object, it will hide the first exception. ------------------------------------------------------- Date: 2000-Aug-31 17:56 By: jhylton Comment: Address Barry's comments ------------------------------------------------------- Date: 2000-Aug-31 19:02 By: gvanrossum Comment: OK, check it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101346&group_id=5470 From noreply@sourceforge.net Fri Sep 1 03:10:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 19:10:38 -0700 Subject: [Patches] [Patch #100998] experimental support for extended slicing on lists Message-ID: <200009010210.TAA28420@bush.i.sourceforge.net> Patch #100998 has been updated. Project: Category: core (C code) Status: Postponed Summary: experimental support for extended slicing on lists Follow-Ups: Date: 2000-Jul-27 14:31 By: mwh Comment: this 10 minute hack adds support for "extended slicing" to lists, by which I mean things like: >>> range(100)[23:60:12] [23, 35, 47, 59] todo: find out if this is the approved approach add support for tuples write docs, testsuite (make test passes as is, but should be extended). ------------------------------------------------------- Date: 2000-Jul-27 14:39 By: mwh Comment: c'mon michael! at least get *some* of the boundary cases... ------------------------------------------------------- Date: 2000-Jul-27 23:47 By: mwh Comment: negative indices! for i in listvar[::-1]: pass now iterates over the list backwards (rather than coredumping...) ------------------------------------------------------- Date: 2000-Jul-29 03:36 By: mwh Comment: updated patch to support slice assignements, deletions (needs testing still) ------------------------------------------------------- Date: 2000-Jul-30 11:10 By: mwh Comment: bugfixes (refounting in assignment, logic in deletion) & a few tweaks. ------------------------------------------------------- Date: 2000-Jul-30 11:41 By: mwh Comment: meep! naughty Michael hadn't been running "make test" often enough. this update fixes that. ------------------------------------------------------- Date: 2000-Aug-15 11:53 By: tim_one Comment: Note that without doc and test patches too, and Real Soon, I'll have to Postpone this. Assigned to me to remind me of that. ------------------------------------------------------- Date: 2000-Aug-15 12:04 By: mwh Comment: OK, I'll get to that soon (ie. <24hours, hopefully <4). But bear in mind I'm now going to the pub... I may need some advice for the docs... ------------------------------------------------------- Date: 2000-Aug-16 12:30 By: mwh Comment: So, I missed my deadline by twenty five minutes. Sorry :-) This latest patch adds a fairly basic test suite, a stab at some docs, and jumps up and down on PySlice_GetIndices. Also (wrt. stringobject.c & unicodeobject.c) it's amazing what you can break, isn't it? Thank God for test suites... ------------------------------------------------------- Date: 2000-Aug-16 12:30 By: mwh Comment: So, I missed my deadline by twenty five minutes. Sorry :-) This latest patch adds a fairly basic test suite, a stab at some docs, and jumps up and down on PySlice_GetIndices. Also (wrt. stringobject.c & unicodeobject.c) it's amazing what you can break, isn't it? Thank God for test suites... ------------------------------------------------------- Date: 2000-Aug-31 19:10 By: gvanrossum Comment: Too late for the release, sorry. And Tim hates negative strides. We'll get back to this for 2.1. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100998&group_id=5470 From noreply@sourceforge.net Fri Sep 1 03:15:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 19:15:52 -0700 Subject: [Patches] [Patch #100895] safe version of PyErr_Format Message-ID: <200009010215.TAA28551@bush.i.sourceforge.net> Patch #100895 has been updated. Project: Category: core (C code) Status: Open Summary: safe version of PyErr_Format Follow-Ups: Date: 2000-Jul-17 14:56 By: effbot Comment: minor tweaks (mostly comments), based on input from moshe. ------------------------------------------------------- Date: 2000-Jul-17 23:23 By: moshez Comment: I'm +1 on that! It will plug one more security hole in Python, and seems a "good enough" replacement for an unsure snprintf() ------------------------------------------------------- Date: 2000-Aug-08 10:19 By: effbot Comment: regenerated, since moshez reported that it didn't apply cleanly to the current CVS tree. reassigned, since it's been sitting here for ages. ------------------------------------------------------- Date: 2000-Aug-10 21:04 By: tim_one Comment: Rejected and back to /F. Major: no docs! Format strings processed by this have different semantics than anyone could guess (e.g., flags are ignored, width is ignored, some format codes are copied verbatim). Reverse-engineering the code each time there's a question is just too painful. You're basically inventing a new sublanguage here, so document what the heck it is & means. Mechanical: There's a "step 1" but no "step 2" . We shouldn't be #ifdef'ing on prototypes anymore. Guido did not yield to the push for 4-space indents in C code, so this should use hard tabs. ------------------------------------------------------- Date: 2000-Aug-15 17:05 By: tim_one Comment: Changed status from Rejeced to Open so we only have to look in one place for the status of putative 2.0 patches. But the patch is still *effectively* rejected pending response to the objections. ------------------------------------------------------- Date: 2000-Aug-21 18:42 By: tim_one Comment: Just reminding you this is still on your plate. ------------------------------------------------------- Date: 2000-Aug-23 02:32 By: moshez Comment: Here's a summary, for a future documentation patch: PyObject *PyErr_Format(PyObject *exception, char *fmt, ...) exception should be a Python object. "fmt" should be a string, containing format codes, similar to "printf". width.precision is parsed, but the width part is ignored. Formatting characters --------------------- 'c' -- format a character, as an "int" argument 'd' -- format a number in decimal, as an "int" argument 'x' -- format a number in hex, as an "int" argument 's' -- format a C string, as a "char *" argument An unrecognized format character causes all the rest of the format string to be copied as-is to the result string, and any extra arguments discarded. A new reference is returned, which is owned by the caller. I don't want to clobber the patch with an API docs patch, but the above should be pretty much cut-and-pastable (or, if not, tell me what's wrong and I'll try and fix it) ------------------------------------------------------- Date: 2000-Aug-31 19:15 By: gvanrossum Comment: Jeremy, if this works for you, check it in and pass it on (as Accepted) to Fred just for the docs. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100895&group_id=5470 From noreply@sourceforge.net Fri Sep 1 03:12:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 19:12:06 -0700 Subject: [Patches] [Patch #100895] safe version of PyErr_Format Message-ID: <200009010212.TAA23089@delerium.i.sourceforge.net> Patch #100895 has been updated. Project: Category: core (C code) Status: Open Summary: safe version of PyErr_Format Follow-Ups: Date: 2000-Jul-17 14:56 By: effbot Comment: minor tweaks (mostly comments), based on input from moshe. ------------------------------------------------------- Date: 2000-Jul-17 23:23 By: moshez Comment: I'm +1 on that! It will plug one more security hole in Python, and seems a "good enough" replacement for an unsure snprintf() ------------------------------------------------------- Date: 2000-Aug-08 10:19 By: effbot Comment: regenerated, since moshez reported that it didn't apply cleanly to the current CVS tree. reassigned, since it's been sitting here for ages. ------------------------------------------------------- Date: 2000-Aug-10 21:04 By: tim_one Comment: Rejected and back to /F. Major: no docs! Format strings processed by this have different semantics than anyone could guess (e.g., flags are ignored, width is ignored, some format codes are copied verbatim). Reverse-engineering the code each time there's a question is just too painful. You're basically inventing a new sublanguage here, so document what the heck it is & means. Mechanical: There's a "step 1" but no "step 2" . We shouldn't be #ifdef'ing on prototypes anymore. Guido did not yield to the push for 4-space indents in C code, so this should use hard tabs. ------------------------------------------------------- Date: 2000-Aug-15 17:05 By: tim_one Comment: Changed status from Rejeced to Open so we only have to look in one place for the status of putative 2.0 patches. But the patch is still *effectively* rejected pending response to the objections. ------------------------------------------------------- Date: 2000-Aug-21 18:42 By: tim_one Comment: Just reminding you this is still on your plate. ------------------------------------------------------- Date: 2000-Aug-23 02:32 By: moshez Comment: Here's a summary, for a future documentation patch: PyObject *PyErr_Format(PyObject *exception, char *fmt, ...) exception should be a Python object. "fmt" should be a string, containing format codes, similar to "printf". width.precision is parsed, but the width part is ignored. Formatting characters --------------------- 'c' -- format a character, as an "int" argument 'd' -- format a number in decimal, as an "int" argument 'x' -- format a number in hex, as an "int" argument 's' -- format a C string, as a "char *" argument An unrecognized format character causes all the rest of the format string to be copied as-is to the result string, and any extra arguments discarded. A new reference is returned, which is owned by the caller. I don't want to clobber the patch with an API docs patch, but the above should be pretty much cut-and-pastable (or, if not, tell me what's wrong and I'll try and fix it) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100895&group_id=5470 From noreply@sourceforge.net Fri Sep 1 03:47:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 19:47:54 -0700 Subject: [Patches] [Patch #101346] print warning if exception occurs in GC Message-ID: <200009010247.TAA24233@delerium.i.sourceforge.net> Patch #101346 has been updated. Project: Category: core (C code) Status: Closed Summary: print warning if exception occurs in GC Follow-Ups: Date: 2000-Aug-29 12:29 By: jhylton Comment: This appears to fix #110915 on Linux. It's not entirely clear that I've but the fetch/restore in the right place, but I think that all collections begin with collect_generations. ------------------------------------------------------- Date: 2000-Aug-29 13:34 By: jhylton Comment: Get rid of the PyErr_Clear that was causing problems and make sure we always restore the exception state before leaving collect_generations. Further, copy code from __del__ to print a message on stderr if the garbage collector did raise an exception. It seems dangerous to ignore one completely, but it's not clear how to recover. If the latter change makes any sense, we'll need to extract the two copies of the code (from classobject.c and gcmodule.c) and put a helper function in errors.c ------------------------------------------------------- Date: 2000-Aug-30 06:40 By: marangoz Comment: Hm. The offending PyErr_Clear should definitely be removed. Not sure that surrounding the collection process with err fetch/restore is a good idea though. The collector could trigger __del__ methods which in turn could set exceptions. The GC code itself should be absolutely transparent w.r.t. exceptions and should propagate them if they're raised elsewhere. So, what needs to be done here is: - remove PyErrClear - use PySys_WriteStderr for debugging. The whole "output" stuff in gcmodule.c should be zapped, because it's a suboptimal and incomplete PySys_WriteStderr. The latter takes care to fetch/restore exceptions when printing the output. PS: now that this is assigned to me, can I upload another patch over this one for review? ------------------------------------------------------- Date: 2000-Aug-30 12:48 By: gvanrossum Comment: We agree with Vladimir. You can't upload a new version to this patch, but you can submit it as a new patch. We still want to check for spurious exceptions in the GC code and turn them into fatal errors, because they shouldn't happen and we want to make sure they don't. ------------------------------------------------------- Date: 2000-Aug-31 14:44 By: jhylton Comment: This is a paranoid safety measure. The GC should not raise any exceptions, and we don't think it does. But just in case, print a message to stderr if an exception does occur. Then raise a fatal error. ------------------------------------------------------- Date: 2000-Aug-31 15:01 By: bwarsaw Comment: Summary: - I'd call the factored out C function PyError_WriteUnraisable() - not sure gcmodule.c's `unhandled' needs to be a static, but perhaps you're worried about unexpected memory errors? - if you keep this variable, maybe call it gcerror. Other than that +1 ------------------------------------------------------- Date: 2000-Aug-31 17:28 By: jhylton Comment: About the static unhandled: Yes. I'm worried because an unexpected exception has already occurred. If another occurs while creating the Python string object, it will hide the first exception. ------------------------------------------------------- Date: 2000-Aug-31 17:56 By: jhylton Comment: Address Barry's comments ------------------------------------------------------- Date: 2000-Aug-31 19:02 By: gvanrossum Comment: OK, check it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101346&group_id=5470 From noreply@sourceforge.net Fri Sep 1 04:14:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 20:14:11 -0700 Subject: [Patches] [Patch #101278] Enable --program-suffix option in configure for Cygwin et. a Message-ID: <200009010314.UAA30439@bush.i.sourceforge.net> Patch #101278 has been updated. Project: Category: Build Status: Rejected Summary: Enable --program-suffix option in configure for Cygwin et. a Follow-Ups: Date: 2000-Aug-30 12:24 By: gvanrossum Comment: Who's going to test it on Cygwin? ------------------------------------------------------- Date: 2000-Aug-31 20:14 By: jhylton Comment: The patch needs to change configure.in not configure. The latter is generated automatically by autoconf. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101278&group_id=5470 From noreply@sourceforge.net Fri Sep 1 04:49:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 20:49:55 -0700 Subject: [Patches] [Patch #100895] safe version of PyErr_Format Message-ID: <200009010349.UAA26249@delerium.i.sourceforge.net> Patch #100895 has been updated. Project: Category: core (C code) Status: Open Summary: safe version of PyErr_Format Follow-Ups: Date: 2000-Jul-17 14:56 By: effbot Comment: minor tweaks (mostly comments), based on input from moshe. ------------------------------------------------------- Date: 2000-Jul-17 23:23 By: moshez Comment: I'm +1 on that! It will plug one more security hole in Python, and seems a "good enough" replacement for an unsure snprintf() ------------------------------------------------------- Date: 2000-Aug-08 10:19 By: effbot Comment: regenerated, since moshez reported that it didn't apply cleanly to the current CVS tree. reassigned, since it's been sitting here for ages. ------------------------------------------------------- Date: 2000-Aug-10 21:04 By: tim_one Comment: Rejected and back to /F. Major: no docs! Format strings processed by this have different semantics than anyone could guess (e.g., flags are ignored, width is ignored, some format codes are copied verbatim). Reverse-engineering the code each time there's a question is just too painful. You're basically inventing a new sublanguage here, so document what the heck it is & means. Mechanical: There's a "step 1" but no "step 2" . We shouldn't be #ifdef'ing on prototypes anymore. Guido did not yield to the push for 4-space indents in C code, so this should use hard tabs. ------------------------------------------------------- Date: 2000-Aug-15 17:05 By: tim_one Comment: Changed status from Rejeced to Open so we only have to look in one place for the status of putative 2.0 patches. But the patch is still *effectively* rejected pending response to the objections. ------------------------------------------------------- Date: 2000-Aug-21 18:42 By: tim_one Comment: Just reminding you this is still on your plate. ------------------------------------------------------- Date: 2000-Aug-23 02:32 By: moshez Comment: Here's a summary, for a future documentation patch: PyObject *PyErr_Format(PyObject *exception, char *fmt, ...) exception should be a Python object. "fmt" should be a string, containing format codes, similar to "printf". width.precision is parsed, but the width part is ignored. Formatting characters --------------------- 'c' -- format a character, as an "int" argument 'd' -- format a number in decimal, as an "int" argument 'x' -- format a number in hex, as an "int" argument 's' -- format a C string, as a "char *" argument An unrecognized format character causes all the rest of the format string to be copied as-is to the result string, and any extra arguments discarded. A new reference is returned, which is owned by the caller. I don't want to clobber the patch with an API docs patch, but the above should be pretty much cut-and-pastable (or, if not, tell me what's wrong and I'll try and fix it) ------------------------------------------------------- Date: 2000-Aug-31 19:15 By: gvanrossum Comment: Jeremy, if this works for you, check it in and pass it on (as Accepted) to Fred just for the docs. ------------------------------------------------------- Date: 2000-Aug-31 20:49 By: jhylton Comment: Code is now checked in. Fred, please review the docs, check them in, then close this patch. Fredrik: Changed itoa to sprintf, as itoa doesn't exist on Linux. Please review the changes. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100895&group_id=5470 From noreply@sourceforge.net Fri Sep 1 04:58:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 20:58:28 -0700 Subject: [Patches] [Patch #100895] safe version of PyErr_Format Message-ID: <200009010358.UAA31906@bush.i.sourceforge.net> Patch #100895 has been updated. Project: Category: core (C code) Status: Open Summary: safe version of PyErr_Format Follow-Ups: Date: 2000-Jul-17 14:56 By: effbot Comment: minor tweaks (mostly comments), based on input from moshe. ------------------------------------------------------- Date: 2000-Jul-17 23:23 By: moshez Comment: I'm +1 on that! It will plug one more security hole in Python, and seems a "good enough" replacement for an unsure snprintf() ------------------------------------------------------- Date: 2000-Aug-08 10:19 By: effbot Comment: regenerated, since moshez reported that it didn't apply cleanly to the current CVS tree. reassigned, since it's been sitting here for ages. ------------------------------------------------------- Date: 2000-Aug-10 21:04 By: tim_one Comment: Rejected and back to /F. Major: no docs! Format strings processed by this have different semantics than anyone could guess (e.g., flags are ignored, width is ignored, some format codes are copied verbatim). Reverse-engineering the code each time there's a question is just too painful. You're basically inventing a new sublanguage here, so document what the heck it is & means. Mechanical: There's a "step 1" but no "step 2" . We shouldn't be #ifdef'ing on prototypes anymore. Guido did not yield to the push for 4-space indents in C code, so this should use hard tabs. ------------------------------------------------------- Date: 2000-Aug-15 17:05 By: tim_one Comment: Changed status from Rejeced to Open so we only have to look in one place for the status of putative 2.0 patches. But the patch is still *effectively* rejected pending response to the objections. ------------------------------------------------------- Date: 2000-Aug-21 18:42 By: tim_one Comment: Just reminding you this is still on your plate. ------------------------------------------------------- Date: 2000-Aug-23 02:32 By: moshez Comment: Here's a summary, for a future documentation patch: PyObject *PyErr_Format(PyObject *exception, char *fmt, ...) exception should be a Python object. "fmt" should be a string, containing format codes, similar to "printf". width.precision is parsed, but the width part is ignored. Formatting characters --------------------- 'c' -- format a character, as an "int" argument 'd' -- format a number in decimal, as an "int" argument 'x' -- format a number in hex, as an "int" argument 's' -- format a C string, as a "char *" argument An unrecognized format character causes all the rest of the format string to be copied as-is to the result string, and any extra arguments discarded. A new reference is returned, which is owned by the caller. I don't want to clobber the patch with an API docs patch, but the above should be pretty much cut-and-pastable (or, if not, tell me what's wrong and I'll try and fix it) ------------------------------------------------------- Date: 2000-Aug-31 19:15 By: gvanrossum Comment: Jeremy, if this works for you, check it in and pass it on (as Accepted) to Fred just for the docs. ------------------------------------------------------- Date: 2000-Aug-31 20:49 By: jhylton Comment: Code is now checked in. Fred, please review the docs, check them in, then close this patch. Fredrik: Changed itoa to sprintf, as itoa doesn't exist on Linux. Please review the changes. ------------------------------------------------------- Date: 2000-Aug-31 20:58 By: fdrake Comment: Moshe: the documentation looks fine from a quick look. Mark up the table using a tableii environment like this: \begin{tableii}{c|l}{character}{Character}{Meaning} \lineii{c}{Character, as an \ctype{int} parameter} ... The ... in the signature should be spelled \moreargs (a fairly new mark). Please don't hesitate to check this in if you can generate the DVI file. Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100895&group_id=5470 From noreply@sourceforge.net Fri Sep 1 05:20:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 21:20:24 -0700 Subject: [Patches] [Patch #100874] Better error message with UnboundLocalError Message-ID: <200009010420.VAA32557@bush.i.sourceforge.net> Patch #100874 has been updated. Project: Category: core (C code) Status: Closed Summary: Better error message with UnboundLocalError Follow-Ups: Date: 2000-Jul-12 21:56 By: tim_one Comment: Rejected and assigned back to Paul. I like the idea fine, the rejection is for style reasons and a repeated security hole. Please make the code look like the rest of ceval.c -- idiosyncracies (that aren't Guido's <0.3 wink>) are harmful in group-maintained code. Examples: > PyObject *nm=NULL; Should be a space on each side of "=". Ditto throughout the patch. BTW, is "nm" meant to be an abbreviation for "name"? If so, please spell out the two extra letters. If it's meant to be an abbreviation for New Mexico, capitalize it . > if(!nm) break; "if" isn't a function call: use a space between "if" and "(". It's also bad to slop "break" on the same line: makes it much harder to set a useful breakpoint here in a debugger. Everywhere else in the code this line would be spelled (if Guido wrote it -- and the "\t" business here is because SF comments don't preserve indentation): \tif (!nm) \t\tbreak > sprintf( buf, "Local variable %s No space between "(" and "buf" here. > PyExc_UnboundLocalError, buf ); No space between "buf" and ")" here. > char buf[500]; > ... followed by an unchecked sprintf into buf. This is a security hole: Python doesn't restrict identifiers to being no longer than 500 chars, so a hacker can easily trick this code into overwriting the buffer bounds. Easy but tedious to fix (e.g., #define the buf length, and use runtime code in conjunction with strncpy to guarantee buf's bounds are respected). ------------------------------------------------------- Date: 2000-Jul-14 14:17 By: prescod Comment: Small helper function format_exc_check_arg makes it easy to generate one string and a argument-type exceptions. It may be overkill in terms of null checking...reviewer can decide. Otherwise, error messages are added to NameErrors and UnboundLocalErrors. That means that all exceptions thrown in ceval have associated error messages. ------------------------------------------------------- Date: 2000-Jul-18 06:32 By: twouters Comment: The helper function is declared 'static', but not defined as such. Rest of the style issues seem solved ;) ------------------------------------------------------- Date: 2000-Jul-25 23:56 By: tim_one Comment: Accepted and assigned back to Paul. Paul, the new format_exc_check_arg function is defined K&R-style, but we've moved to ANSI almost everywhere else in the source. Would be nice if you fix that before checking this in. Else I'll look for it and fix it myself. Sorry for the delay in getting back to this! ------------------------------------------------------- Date: 2000-Aug-15 11:10 By: tim_one Comment: Paul, this was accepted weeks ago. Are you going to check it in? ------------------------------------------------------- Date: 2000-Aug-19 18:47 By: tim_one Comment: Yo! Paul! Check it in already! ------------------------------------------------------- Date: 2000-Aug-21 18:47 By: tim_one Comment: Knock, knock! Anybody home? ------------------------------------------------------- Date: 2000-Aug-31 21:20 By: fdrake Comment: Checked in by Paul on 30 Aug 2000 as ceval.c 2.199; closing it for him. Paul, please remember to close patches after checking them in! Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100874&group_id=5470 From noreply@sourceforge.net Fri Sep 1 07:04:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 23:04:16 -0700 Subject: [Patches] [Patch #101187] Patch for ftplib to support REST Message-ID: <200009010604.XAA03450@bush.i.sourceforge.net> Patch #101187 has been updated. Project: Category: Modules Status: Accepted Summary: Patch for ftplib to support REST Follow-Ups: Date: 2000-Aug-15 15:34 By: tim_one Comment: Assigned to Barry for an opinion. This came in after feature freeze, but it's arguably more of a bugfix than a new feature. If you're capable of making that decision with more confidence than me, please Postpone it or assign it to a competent (not me) reviewer for 2.0. ------------------------------------------------------- Date: 2000-Aug-22 00:09 By: moshez Comment: This seems great, and I'm very +1, except for one thing: the ``self.sendcmd("REST %.0f" % rest)'' thing: wouldn't it be better to self.sendcmd("REST %d" % int(rest))? Other then that, it seems to do nothing when the rest argument is not given, so it can't hurt too much. Oh, and of course, this needs doc patches. ------------------------------------------------------- Date: 2000-Aug-22 08:33 By: none Comment: I realized some problem yesterday ... ftp-daemons which do not support REST throw a 502 exception ------------------------------------------------------- Date: 2000-Aug-22 09:05 By: preisl Comment: Ok, forget my last commet (yep, it was me, who forgot to login) ... I think it's ok that the ftplib throws the exception, since the user knows, that he mustn't use the rest parameter then. ------------------------------------------------------- Date: 2000-Aug-24 07:59 By: moshez Comment: OK, here's a stab at what's needed for documentation changes: Add to the prototype of the "ntransfercmd()" and "transfercmd" an \optional{, rest} and to the description a paragraph: If the \var{rest} parameter is given, it should be an integer, specifying how many initial bytes of the file the tranfer command should ignore. If the FTP server does not support the \code{REST} command, and the \var{rest} argument is used, an exception will be raised. Programs might want to deal with it by initiating a transfer without \var{rest}, and ignore the first \var{rest} bytes. (Of course, this option is much more costly in terms of time and network resources used.) ------------------------------------------------------- Date: 2000-Aug-26 08:55 By: preisl Comment: Agreed to the doc ... but please stick to te %.0f, restricting to %d would limit the filesize to about 2gb which might be enough now, but probably not for the future. ------------------------------------------------------- Date: 2000-Aug-31 23:04 By: bwarsaw Comment: RFC 959 says that the argument to REST is a "marker", essentially a string containing any ASCII characters in the range [33..126]. So the argument should be interpolated into the string with %s, not %d or %f I don't believe it's worth sanity checking the the argument to make sure all characters fall within this range, but it should be included in the documentation. I will accept this patch, and make this change when I check it in. I'll also make the patch conform to Python coding standards - compare to None using "is" and "is not" instead of == an != - no parens around comparison ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101187&group_id=5470 From noreply@sourceforge.net Fri Sep 1 07:10:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 23:10:06 -0700 Subject: [Patches] [Patch #101187] Patch for ftplib to support REST Message-ID: <200009010610.XAA03632@bush.i.sourceforge.net> Patch #101187 has been updated. Project: Category: Modules Status: Closed Summary: Patch for ftplib to support REST Follow-Ups: Date: 2000-Aug-15 15:34 By: tim_one Comment: Assigned to Barry for an opinion. This came in after feature freeze, but it's arguably more of a bugfix than a new feature. If you're capable of making that decision with more confidence than me, please Postpone it or assign it to a competent (not me) reviewer for 2.0. ------------------------------------------------------- Date: 2000-Aug-22 00:09 By: moshez Comment: This seems great, and I'm very +1, except for one thing: the ``self.sendcmd("REST %.0f" % rest)'' thing: wouldn't it be better to self.sendcmd("REST %d" % int(rest))? Other then that, it seems to do nothing when the rest argument is not given, so it can't hurt too much. Oh, and of course, this needs doc patches. ------------------------------------------------------- Date: 2000-Aug-22 08:33 By: none Comment: I realized some problem yesterday ... ftp-daemons which do not support REST throw a 502 exception ------------------------------------------------------- Date: 2000-Aug-22 09:05 By: preisl Comment: Ok, forget my last commet (yep, it was me, who forgot to login) ... I think it's ok that the ftplib throws the exception, since the user knows, that he mustn't use the rest parameter then. ------------------------------------------------------- Date: 2000-Aug-24 07:59 By: moshez Comment: OK, here's a stab at what's needed for documentation changes: Add to the prototype of the "ntransfercmd()" and "transfercmd" an \optional{, rest} and to the description a paragraph: If the \var{rest} parameter is given, it should be an integer, specifying how many initial bytes of the file the tranfer command should ignore. If the FTP server does not support the \code{REST} command, and the \var{rest} argument is used, an exception will be raised. Programs might want to deal with it by initiating a transfer without \var{rest}, and ignore the first \var{rest} bytes. (Of course, this option is much more costly in terms of time and network resources used.) ------------------------------------------------------- Date: 2000-Aug-26 08:55 By: preisl Comment: Agreed to the doc ... but please stick to te %.0f, restricting to %d would limit the filesize to about 2gb which might be enough now, but probably not for the future. ------------------------------------------------------- Date: 2000-Aug-31 23:04 By: bwarsaw Comment: RFC 959 says that the argument to REST is a "marker", essentially a string containing any ASCII characters in the range [33..126]. So the argument should be interpolated into the string with %s, not %d or %f I don't believe it's worth sanity checking the the argument to make sure all characters fall within this range, but it should be included in the documentation. I will accept this patch, and make this change when I check it in. I'll also make the patch conform to Python coding standards - compare to None using "is" and "is not" instead of == an != - no parens around comparison ------------------------------------------------------- Date: 2000-Aug-31 23:10 By: bwarsaw Comment: Applied, with the described changes. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101187&group_id=5470 From noreply@sourceforge.net Fri Sep 1 07:40:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 23:40:08 -0700 Subject: [Patches] [Patch #101350] Fix SMTPlib for large messages Message-ID: <200009010640.XAA31582@delerium.i.sourceforge.net> Patch #101350 has been updated. Project: Category: library Status: Closed Summary: Fix SMTPlib for large messages Follow-Ups: Date: 2000-Aug-31 23:40 By: bwarsaw Comment: Applied. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101350&group_id=5470 From noreply@sourceforge.net Fri Sep 1 07:50:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 23:50:22 -0700 Subject: [Patches] [Patch #100994] Allow JPython to use more tests Message-ID: <200009010650.XAA04842@bush.i.sourceforge.net> Patch #100994 has been updated. Project: Category: library Status: Closed Summary: Allow JPython to use more tests Follow-Ups: Date: 2000-Jul-27 12:47 By: bckfnn Comment: Several test can almost but not quite be used from JPython. test_b1: JPython does no longer have a strop module. Instead the builtin "time" module is used. test_exceptions.py: In JPython the builtin exception does not have type ClassType but type TypeType. The TypeType is a subclass of ClassType which make the isinstance work for both pythons. test_pkg.py: JPython does not insert __builtins__ in the module namespace. I hope that removing __builtins__ from the output does not devaluate the test. ------------------------------------------------------- Date: 2000-Jul-27 12:52 By: gvanrossum Comment: Note that Lib/test/output/test_pkg must be changed too! Regenerate it by running "regrtest.py -g test_pkh". ------------------------------------------------------- Date: 2000-Aug-15 11:07 By: tim_one Comment: Reassigned to Barry in Jeremy's absence. Barry, note that Guido already Accepted this. If you do too, check it in. ------------------------------------------------------- Date: 2000-Aug-21 18:52 By: tim_one Comment: Barry, this is still on your plate. Eat it or give it to a starving child. ------------------------------------------------------- Date: 2000-Aug-31 23:50 By: bwarsaw Comment: Accepted and applied. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100994&group_id=5470 From noreply@sourceforge.net Fri Sep 1 09:06:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 1 Sep 2000 01:06:34 -0700 Subject: [Patches] [Patch #101295] New tool msgfmt.py Message-ID: <200009010806.BAA07259@bush.i.sourceforge.net> Patch #101295 has been updated. Project: Category: demos and tools Status: Accepted Summary: New tool msgfmt.py Follow-Ups: Date: 2000-Sep-01 01:06 By: bwarsaw Comment: Yes, this tool should be added to the distribution. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101295&group_id=5470 From noreply@sourceforge.net Fri Sep 1 09:08:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 1 Sep 2000 01:08:16 -0700 Subject: [Patches] [Patch #101295] New tool msgfmt.py Message-ID: <200009010808.BAA07373@bush.i.sourceforge.net> Patch #101295 has been updated. Project: Category: demos and tools Status: Closed Summary: New tool msgfmt.py Follow-Ups: Date: 2000-Sep-01 01:06 By: bwarsaw Comment: Yes, this tool should be added to the distribution. ------------------------------------------------------- Date: 2000-Sep-01 01:08 By: bwarsaw Comment: Adding this to Tools/i18n after cleaning it up, fixing typos, coding standards, and where options overlap with GNU msgfmt, make them compatible. The checked in version will be slightly different than the patch below. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101295&group_id=5470 From noreply@sourceforge.net Fri Sep 1 09:54:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 1 Sep 2000 01:54:41 -0700 Subject: [Patches] [Patch #101387] Documenting __contains__ special method Message-ID: <200009010854.BAA08882@bush.i.sourceforge.net> Patch #101387 has been updated. Project: Category: documentation Status: Open Summary: Documenting __contains__ special method ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101387&group_id=5470 From noreply@sourceforge.net Fri Sep 1 09:56:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 1 Sep 2000 01:56:43 -0700 Subject: [Patches] [Patch #101388] Backward compatibility hook Message-ID: <200009010856.BAA08919@bush.i.sourceforge.net> Patch #101388 has been updated. Project: Category: documentation Status: Open Summary: Backward compatibility hook ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101388&group_id=5470 From noreply@sourceforge.net Fri Sep 1 09:57:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 1 Sep 2000 01:57:38 -0700 Subject: [Patches] [Patch #101389] Minor fix in documentation of code module Message-ID: <200009010857.BAA08929@bush.i.sourceforge.net> Patch #101389 has been updated. Project: Category: documentation Status: Open Summary: Minor fix in documentation of code module ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101389&group_id=5470 From noreply@sourceforge.net Fri Sep 1 09:59:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 1 Sep 2000 01:59:05 -0700 Subject: [Patches] [Patch #101390] Add special names to operator module as expected by user Message-ID: <200009010859.BAA09043@bush.i.sourceforge.net> Patch #101390 has been updated. Project: Category: library Status: Open Summary: Add special names to operator module as expected by user ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101390&group_id=5470 From noreply@sourceforge.net Fri Sep 1 10:00:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 1 Sep 2000 02:00:18 -0700 Subject: [Patches] [Patch #101391] Implemented UserList.__contains__ Message-ID: <200009010900.CAA09074@bush.i.sourceforge.net> Patch #101391 has been updated. Project: Category: Modules Status: Open Summary: Implemented UserList.__contains__ ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101391&group_id=5470 From noreply@sourceforge.net Fri Sep 1 14:00:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 1 Sep 2000 06:00:45 -0700 Subject: [Patches] [Patch #100895] safe version of PyErr_Format Message-ID: <200009011300.GAA17251@bush.i.sourceforge.net> Patch #100895 has been updated. Project: Category: core (C code) Status: Closed Summary: safe version of PyErr_Format Follow-Ups: Date: 2000-Jul-17 14:56 By: effbot Comment: minor tweaks (mostly comments), based on input from moshe. ------------------------------------------------------- Date: 2000-Jul-17 23:23 By: moshez Comment: I'm +1 on that! It will plug one more security hole in Python, and seems a "good enough" replacement for an unsure snprintf() ------------------------------------------------------- Date: 2000-Aug-08 10:19 By: effbot Comment: regenerated, since moshez reported that it didn't apply cleanly to the current CVS tree. reassigned, since it's been sitting here for ages. ------------------------------------------------------- Date: 2000-Aug-10 21:04 By: tim_one Comment: Rejected and back to /F. Major: no docs! Format strings processed by this have different semantics than anyone could guess (e.g., flags are ignored, width is ignored, some format codes are copied verbatim). Reverse-engineering the code each time there's a question is just too painful. You're basically inventing a new sublanguage here, so document what the heck it is & means. Mechanical: There's a "step 1" but no "step 2" . We shouldn't be #ifdef'ing on prototypes anymore. Guido did not yield to the push for 4-space indents in C code, so this should use hard tabs. ------------------------------------------------------- Date: 2000-Aug-15 17:05 By: tim_one Comment: Changed status from Rejeced to Open so we only have to look in one place for the status of putative 2.0 patches. But the patch is still *effectively* rejected pending response to the objections. ------------------------------------------------------- Date: 2000-Aug-21 18:42 By: tim_one Comment: Just reminding you this is still on your plate. ------------------------------------------------------- Date: 2000-Aug-23 02:32 By: moshez Comment: Here's a summary, for a future documentation patch: PyObject *PyErr_Format(PyObject *exception, char *fmt, ...) exception should be a Python object. "fmt" should be a string, containing format codes, similar to "printf". width.precision is parsed, but the width part is ignored. Formatting characters --------------------- 'c' -- format a character, as an "int" argument 'd' -- format a number in decimal, as an "int" argument 'x' -- format a number in hex, as an "int" argument 's' -- format a C string, as a "char *" argument An unrecognized format character causes all the rest of the format string to be copied as-is to the result string, and any extra arguments discarded. A new reference is returned, which is owned by the caller. I don't want to clobber the patch with an API docs patch, but the above should be pretty much cut-and-pastable (or, if not, tell me what's wrong and I'll try and fix it) ------------------------------------------------------- Date: 2000-Aug-31 19:15 By: gvanrossum Comment: Jeremy, if this works for you, check it in and pass it on (as Accepted) to Fred just for the docs. ------------------------------------------------------- Date: 2000-Aug-31 20:49 By: jhylton Comment: Code is now checked in. Fred, please review the docs, check them in, then close this patch. Fredrik: Changed itoa to sprintf, as itoa doesn't exist on Linux. Please review the changes. ------------------------------------------------------- Date: 2000-Aug-31 20:58 By: fdrake Comment: Moshe: the documentation looks fine from a quick look. Mark up the table using a tableii environment like this: \begin{tableii}{c|l}{character}{Character}{Meaning} \lineii{c}{Character, as an \ctype{int} parameter} ... The ... in the signature should be spelled \moreargs (a fairly new mark). Please don't hesitate to check this in if you can generate the DVI file. Thanks! ------------------------------------------------------- Date: 2000-Sep-01 06:00 By: fdrake Comment: Checked in by Moshe; I'm closing this since his connection is flaky. Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100895&group_id=5470 From noreply@sourceforge.net Fri Sep 1 14:54:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 1 Sep 2000 06:54:48 -0700 Subject: [Patches] [Patch #100955] ptags, eptags: regex->re, 4 char indent. Message-ID: <200009011354.GAA14030@delerium.i.sourceforge.net> Patch #100955 has been updated. Project: Category: None Status: Closed Summary: ptags, eptags: regex->re, 4 char indent. Follow-Ups: Date: 2000-Jul-22 01:35 By: hooft Comment: This is another time waster. But now at least I know how a TAGS file is constructed, and I know that re is a lot slower than regex. ------------------------------------------------------- Date: 2000-Jul-22 23:44 By: moshez Comment: I'm not sure that this patch is worth it -- it seems backwards to analyse Python programs with re -- why not simply use the parser module if we really want this? ------------------------------------------------------- Date: 2000-Jul-25 13:57 By: gvanrossum Comment: SRE should be faster again, right? The parser module is a very big gun for this simple app -- look at it as an example for text processing (and documentation for TAGS files :-). I say go for it. ------------------------------------------------------- Date: 2000-Jul-26 07:12 By: moshez Comment: Somehow it passed through me, so I added ptags change too. Anyway, Jeremy, Guido is for this. ------------------------------------------------------- Date: 2000-Aug-15 11:12 By: tim_one Comment: Reassigned to Barry in Jeremy's absence, cuz Barry is da Emacs dude. This was already Accepted; if you agree, please check it in and Close it. ------------------------------------------------------- Date: 2000-Aug-15 11:13 By: tim_one Comment: Reassigned to Barry in Jeremy's absence, cuz Barry is da Emacs dude. This was already Accepted; if you agree, please check it in and Close it. ------------------------------------------------------- Date: 2000-Aug-15 11:13 By: tim_one Comment: Reassigned to Barry in Jeremy's absence, cuz Barry is da Emacs dude. This was already Accepted; if you agree, please check it in and Close it. ------------------------------------------------------- Date: 2000-Aug-21 18:51 By: tim_one Comment: Barry, please follow up on this, or assign it to someone else. ------------------------------------------------------- Date: 2000-Sep-01 06:54 By: gvanrossum Comment: Checked in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100955&group_id=5470 From noreply@sourceforge.net Fri Sep 1 15:41:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 1 Sep 2000 07:41:07 -0700 Subject: [Patches] [Patch #101388] Backward compatibility hook Message-ID: <200009011441.HAA15789@delerium.i.sourceforge.net> Patch #101388 has been updated. Project: Category: documentation Status: Postponed Summary: Backward compatibility hook Follow-Ups: Date: 2000-Sep-01 07:41 By: jhylton Comment: same deal: postponed for now, but may be considered post 2.0b1 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101388&group_id=5470 From noreply@sourceforge.net Fri Sep 1 15:42:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 1 Sep 2000 07:42:06 -0700 Subject: [Patches] [Patch #101389] Minor fix in documentation of code module Message-ID: <200009011442.HAA15896@delerium.i.sourceforge.net> Patch #101389 has been updated. Project: Category: documentation Status: Open Summary: Minor fix in documentation of code module ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101389&group_id=5470 From noreply@sourceforge.net Fri Sep 1 15:22:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 1 Sep 2000 07:22:45 -0700 Subject: [Patches] [Patch #101121] cosmetic cleanup of cgi.py, using Guido's style conventions Message-ID: <200009011422.HAA20234@bush.i.sourceforge.net> Patch #101121 has been updated. Project: Category: library Status: Postponed Summary: cosmetic cleanup of cgi.py, using Guido's style conventions Follow-Ups: Date: 2000-Aug-08 13:37 By: ping Comment: This is an immediate follow-on to #101120 (i just wanted to keep the semantic and non-semantic changes separate). ------------------------------------------------------- Date: 2000-Aug-15 15:06 By: tim_one Comment: I'm not sure what you mean by "follow-on". If this patch is *independent* of 101120, just Accept it yourself and check it in -- there's no need to go thru a review process for mechanical cleanup. Assigning to you on that basis. Ah, and you *can* check it in, in about 6 hours: you've been added to the Python project as a Developer. That means I get to assign patches to you for review, too From noreply@sourceforge.net Fri Sep 1 15:42:27 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 1 Sep 2000 07:42:27 -0700 Subject: [Patches] [Patch #101390] Add special names to operator module as expected by user Message-ID: <200009011442.HAA15901@delerium.i.sourceforge.net> Patch #101390 has been updated. Project: Category: library Status: Postponed Summary: Add special names to operator module as expected by user Follow-Ups: Date: 2000-Sep-01 07:42 By: jhylton Comment: third one: postponed for now ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101390&group_id=5470 From noreply@sourceforge.net Fri Sep 1 15:43:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 1 Sep 2000 07:43:05 -0700 Subject: [Patches] [Patch #101389] Minor fix in documentation of code module Message-ID: <200009011443.HAA15939@delerium.i.sourceforge.net> Patch #101389 has been updated. Project: Category: documentation Status: Postponed Summary: Minor fix in documentation of code module ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101389&group_id=5470 From noreply@sourceforge.net Fri Sep 1 15:38:51 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 1 Sep 2000 07:38:51 -0700 Subject: [Patches] [Patch #101387] Documenting __contains__ special method Message-ID: <200009011438.HAA15752@delerium.i.sourceforge.net> Patch #101387 has been updated. Project: Category: documentation Status: Postponed Summary: Documenting __contains__ special method Follow-Ups: Date: 2000-Sep-01 07:38 By: jhylton Comment: Moshe please review but do not accept or check in until we give you the go ahead. These patches arrived too late for 2.0b1. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101387&group_id=5470 From noreply@sourceforge.net Fri Sep 1 15:42:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 1 Sep 2000 07:42:47 -0700 Subject: [Patches] [Patch #101391] Implemented UserList.__contains__ Message-ID: <200009011442.HAA15914@delerium.i.sourceforge.net> Patch #101391 has been updated. Project: Category: Modules Status: Postponed Summary: Implemented UserList.__contains__ Follow-Ups: Date: 2000-Sep-01 07:42 By: jhylton Comment: you know the drill ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101391&group_id=5470 From noreply@sourceforge.net Fri Sep 1 22:13:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 1 Sep 2000 14:13:18 -0700 Subject: [Patches] [Patch #101394] lookdict optimizations Message-ID: <200009012113.OAA03062@bush.i.sourceforge.net> Patch #101394 has been updated. Project: Category: core (C code) Status: Open Summary: lookdict optimizations ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101394&group_id=5470 From noreply@sourceforge.net Sat Sep 2 08:33:26 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 2 Sep 2000 00:33:26 -0700 Subject: [Patches] [Patch #101396] sre_parse.py missing '7' in DIGITS Message-ID: <200009020733.AAA17309@delerium.i.sourceforge.net> Patch #101396 has been updated. Project: Category: library Status: Open Summary: sre_parse.py missing '7' in DIGITS ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101396&group_id=5470 From noreply@sourceforge.net Sat Sep 2 08:48:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 2 Sep 2000 00:48:16 -0700 Subject: [Patches] [Patch #101396] sre_parse.py missing '7' in DIGITS Message-ID: <200009020748.AAA23162@bush.i.sourceforge.net> Patch #101396 has been updated. Project: Category: library Status: Closed Summary: sre_parse.py missing '7' in DIGITS Follow-Ups: Date: 2000-Sep-02 00:48 By: tim_one Comment: Accepted, applied, and closed. Thanks! /F, assigned to you just FYI. Python uses the American digit system . ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101396&group_id=5470 From noreply@sourceforge.net Sat Sep 2 18:06:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 2 Sep 2000 10:06:06 -0700 Subject: [Patches] [Patch #101398] Fix docs on PyNumber_And and PyNumber_Or Message-ID: <200009021706.KAA08301@bush.i.sourceforge.net> Patch #101398 has been updated. Project: Category: documentation Status: Open Summary: Fix docs on PyNumber_And and PyNumber_Or ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101398&group_id=5470 From noreply@sourceforge.net Sat Sep 2 18:08:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 2 Sep 2000 10:08:36 -0700 Subject: [Patches] [Patch #101398] Fix docs on PyNumber_And and PyNumber_Or Message-ID: <200009021708.KAA08332@bush.i.sourceforge.net> Patch #101398 has been updated. Project: Category: documentation Status: Open Summary: Fix docs on PyNumber_And and PyNumber_Or Follow-Ups: Date: 2000-Sep-02 10:08 By: twouters Comment: the API docs state that 'PyNumber_And' and 'PyNumber_Or' are equivalent to 'o1 and o2' and 'o1 or o2' respectively. This is wrong, they are equivalent to 'o1 & o2' and 'o1 | o2', respectively. I'm not sure whether | needs to be escaped or not, in TeX, so I escaped it just in case. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101398&group_id=5470 From noreply@sourceforge.net Sat Sep 2 18:30:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 2 Sep 2000 10:30:07 -0700 Subject: [Patches] [Patch #101398] Fix docs on PyNumber_And and PyNumber_Or Message-ID: <200009021730.KAA09096@bush.i.sourceforge.net> Patch #101398 has been updated. Project: Category: documentation Status: Open Summary: Fix docs on PyNumber_And and PyNumber_Or Follow-Ups: Date: 2000-Sep-02 10:08 By: twouters Comment: the API docs state that 'PyNumber_And' and 'PyNumber_Or' are equivalent to 'o1 and o2' and 'o1 or o2' respectively. This is wrong, they are equivalent to 'o1 & o2' and 'o1 | o2', respectively. I'm not sure whether | needs to be escaped or not, in TeX, so I escaped it just in case. ------------------------------------------------------- Date: 2000-Sep-02 10:30 By: twouters Comment: Updated patch, which rewords the PyNumber_And, PyNumber_Or and PyNumber_Xor descriptions to make them slightly more obvious. (note: the use of ``'s and '''s is taken from the old descriptions, there might be a better \TeX{dingus} for it.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101398&group_id=5470 From noreply@sourceforge.net Mon Sep 4 02:13:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 3 Sep 2000 18:13:57 -0700 Subject: [Patches] [Patch #101412] add gc.DEBUG_SAVEALL option, gc_str fix Message-ID: <200009040113.SAA05861@bush.i.sourceforge.net> Patch #101412 has been updated. Project: Category: core (C code) Status: Open Summary: add gc.DEBUG_SAVEALL option, gc_str fix ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101412&group_id=5470 From noreply@sourceforge.net Mon Sep 4 04:13:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 3 Sep 2000 20:13:11 -0700 Subject: [Patches] [Patch #101412] add gc.DEBUG_SAVEALL option, gc_str fix Message-ID: <200009040313.UAA05140@delerium.i.sourceforge.net> Patch #101412 has been updated. Project: Category: core (C code) Status: Open Summary: add gc.DEBUG_SAVEALL option, gc_str fix Follow-Ups: Date: 2000-Sep-03 20:13 By: marangoz Comment: Looks good. I approve the str fix. One nit: "else" clauses usually go to a new line in the Python source. Make it "else if" on a new line. Questions: - DEBUG_LEAK now includes SAVEALL. The regression test suite sets DEBUG_LEAK by default. It used to report a bunch of objects during test_gc. Now it will collect the detected cycles in the suite. Should regrtest.py report them somehow? - After the regression test, gc.garbage contains an A instance and an empty list. I think they're created by test_gc. Can't they be cleared? We can assign gc.garbage = [], but this doesn't clear anything. - test_gc/test_saveall has gc.set_debug(0), followed immediately by gc.set_debug(gc.DEBUG_SAVEALL). Is this on purpose or is it a typo? BTW, I don't quite understand why this function does what it does... Could you elaborate on it? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101412&group_id=5470 From noreply@sourceforge.net Mon Sep 4 05:09:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 3 Sep 2000 21:09:18 -0700 Subject: [Patches] [Patch #101394] lookdict optimizations Message-ID: <200009040409.VAA11376@bush.i.sourceforge.net> Patch #101394 has been updated. Project: Category: core (C code) Status: Open Summary: lookdict optimizations Follow-Ups: Date: 2000-Sep-03 21:09 By: marangoz Comment: Let's add a comment, although this has been raised on python-dev. This patch proposes a couple of ideas for optimizing & speeding dict lookups -- not all of them need to be applied though. - clear the eventual errors from Object_Compare only on need (this logic needs to be double-checked once again to see whether it really works) - defer variable initializations after the most common return cases - specialize string_compare() for lookdict_string. The test comparing the first char, before calling memcmp(), can be added too. - inline the first item probe in PyDict_GetItem. This saves a func call for the most common case (common to lookdict & lookdict_string). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101394&group_id=5470 From noreply@sourceforge.net Mon Sep 4 12:25:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 4 Sep 2000 04:25:22 -0700 Subject: [Patches] [Patch #101398] API doc changes (InPlace-API & And/Or/Xor fixes) Message-ID: <200009041125.EAA22162@delerium.i.sourceforge.net> Patch #101398 has been updated. Project: Category: documentation Status: Open Summary: API doc changes (InPlace-API & And/Or/Xor fixes) Follow-Ups: Date: 2000-Sep-02 10:08 By: twouters Comment: the API docs state that 'PyNumber_And' and 'PyNumber_Or' are equivalent to 'o1 and o2' and 'o1 or o2' respectively. This is wrong, they are equivalent to 'o1 & o2' and 'o1 | o2', respectively. I'm not sure whether | needs to be escaped or not, in TeX, so I escaped it just in case. ------------------------------------------------------- Date: 2000-Sep-02 10:30 By: twouters Comment: Updated patch, which rewords the PyNumber_And, PyNumber_Or and PyNumber_Xor descriptions to make them slightly more obvious. (note: the use of ``'s and '''s is taken from the old descriptions, there might be a better \TeX{dingus} for it.) ------------------------------------------------------- Date: 2000-Sep-04 04:25 By: twouters Comment: New version that also includes the docs for the new InPlace API calls. Changed patch summary accordingly. This markup was given a cursory test, and it builds proper .ps/.dvi files, but I'm not a TeX-warrior and there might be better ways. I'm also still working on a new ref-section on augmented assignment, which I hope to finish before heading off to Italy tomorrow (but if I don't manage to finish it, I'll mail my almost-finished stuff, to python-dev or to Fred directly.) Tutorial will have to wait until I'm back or for someone else to do it :P ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101398&group_id=5470 From noreply@sourceforge.net Mon Sep 4 14:45:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 4 Sep 2000 06:45:59 -0700 Subject: [Patches] [Patch #101394] lookdict optimizations Message-ID: <200009041345.GAA26960@delerium.i.sourceforge.net> Patch #101394 has been updated. Project: Category: core (C code) Status: Open Summary: lookdict optimizations Follow-Ups: Date: 2000-Sep-03 21:09 By: marangoz Comment: Let's add a comment, although this has been raised on python-dev. This patch proposes a couple of ideas for optimizing & speeding dict lookups -- not all of them need to be applied though. - clear the eventual errors from Object_Compare only on need (this logic needs to be double-checked once again to see whether it really works) - defer variable initializations after the most common return cases - specialize string_compare() for lookdict_string. The test comparing the first char, before calling memcmp(), can be added too. - inline the first item probe in PyDict_GetItem. This saves a func call for the most common case (common to lookdict & lookdict_string). ------------------------------------------------------- Date: 2000-Sep-04 06:45 By: gvanrossum Comment: Quick comments: we should *always* call PyErr_Occurred() after PyObject_Compare() (and PyErr_Clear() if PyErr_Occurred() returned true). PyErr_Compare() really doesn't expect a pending exception coming in and so *not* clearing the error might break the *next* PyErr_Compare() call. (This doesn't happen typically but PyObject_Compare() can execute arbitrary code, some of which might call PyErr_Occurred() without calling PyErr_Clear() first.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101394&group_id=5470 From noreply@sourceforge.net Mon Sep 4 15:05:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 4 Sep 2000 07:05:53 -0700 Subject: [Patches] [Patch #101412] add gc.DEBUG_SAVEALL option, gc_str fix Message-ID: <200009041405.HAA27714@delerium.i.sourceforge.net> Patch #101412 has been updated. Project: Category: core (C code) Status: Open Summary: add gc.DEBUG_SAVEALL option, gc_str fix Follow-Ups: Date: 2000-Sep-03 20:13 By: marangoz Comment: Looks good. I approve the str fix. One nit: "else" clauses usually go to a new line in the Python source. Make it "else if" on a new line. Questions: - DEBUG_LEAK now includes SAVEALL. The regression test suite sets DEBUG_LEAK by default. It used to report a bunch of objects during test_gc. Now it will collect the detected cycles in the suite. Should regrtest.py report them somehow? - After the regression test, gc.garbage contains an A instance and an empty list. I think they're created by test_gc. Can't they be cleared? We can assign gc.garbage = [], but this doesn't clear anything. - test_gc/test_saveall has gc.set_debug(0), followed immediately by gc.set_debug(gc.DEBUG_SAVEALL). Is this on purpose or is it a typo? BTW, I don't quite understand why this function does what it does... Could you elaborate on it? ------------------------------------------------------- Date: 2000-Sep-04 07:05 By: nascheme Comment: - regrtest will print the repr of cyclic garbage found if -l option is specified and -q is not - put else on newline in accordance with Python style - constrain debugging options during test_gc (don't enabled DEBUG_LEAK) - fix test_gc to remove garbage from gc.garbage ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101412&group_id=5470 From noreply@sourceforge.net Mon Sep 4 17:02:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 4 Sep 2000 09:02:00 -0700 Subject: [Patches] [Patch #101416] coax _sre.c into using Py_GetRecursionLimit() Message-ID: <200009041602.JAA02807@bush.i.sourceforge.net> Patch #101416 has been updated. Project: Category: Modules Status: Open Summary: coax _sre.c into using Py_GetRecursionLimit() ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101416&group_id=5470 From noreply@sourceforge.net Mon Sep 4 17:02:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 4 Sep 2000 09:02:50 -0700 Subject: [Patches] [Patch #101416] coax _sre.c into using Py_GetRecursionLimit() Message-ID: <200009041602.JAA02811@bush.i.sourceforge.net> Patch #101416 has been updated. Project: Category: Modules Status: Open Summary: coax _sre.c into using Py_GetRecursionLimit() Follow-Ups: Date: 2000-Sep-04 09:02 By: montanaro Comment: seems obvious that Fredrik should be the one to handle this... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101416&group_id=5470 From noreply@sourceforge.net Mon Sep 4 21:06:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 4 Sep 2000 13:06:59 -0700 Subject: [Patches] [Patch #101418] More augmented assignment docs Message-ID: <200009042006.NAA08043@delerium.i.sourceforge.net> Patch #101418 has been updated. Project: Category: documentation Status: Open Summary: More augmented assignment docs ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101418&group_id=5470 From noreply@sourceforge.net Mon Sep 4 21:15:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 4 Sep 2000 13:15:54 -0700 Subject: [Patches] [Patch #101418] More augmented assignment docs Message-ID: <200009042015.NAA11759@bush.i.sourceforge.net> Patch #101418 has been updated. Project: Category: documentation Status: Open Summary: More augmented assignment docs Follow-Ups: Date: 2000-Sep-04 13:15 By: twouters Comment: Reference manual docs for augmented assignment. No clue if this actually works, with the \subsection and \indexii things and all, but I did my best ;-P Could still use some crossreferencing, I'm sure. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101418&group_id=5470 From noreply@sourceforge.net Tue Sep 5 13:16:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 5 Sep 2000 05:16:33 -0700 Subject: [Patches] [Patch #101420] auto-detect libdb Message-ID: <200009051216.FAA11515@bush.i.sourceforge.net> Patch #101420 has been updated. Project: Category: Build Status: Open Summary: auto-detect libdb ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101420&group_id=5470 From noreply@sourceforge.net Tue Sep 5 14:05:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 5 Sep 2000 06:05:25 -0700 Subject: [Patches] [Patch #101394] lookdict optimizations Message-ID: <200009051305.GAA09957@delerium.i.sourceforge.net> Patch #101394 has been updated. Project: Category: core (C code) Status: Open Summary: lookdict optimizations Follow-Ups: Date: 2000-Sep-03 21:09 By: marangoz Comment: Let's add a comment, although this has been raised on python-dev. This patch proposes a couple of ideas for optimizing & speeding dict lookups -- not all of them need to be applied though. - clear the eventual errors from Object_Compare only on need (this logic needs to be double-checked once again to see whether it really works) - defer variable initializations after the most common return cases - specialize string_compare() for lookdict_string. The test comparing the first char, before calling memcmp(), can be added too. - inline the first item probe in PyDict_GetItem. This saves a func call for the most common case (common to lookdict & lookdict_string). ------------------------------------------------------- Date: 2000-Sep-04 06:45 By: gvanrossum Comment: Quick comments: we should *always* call PyErr_Occurred() after PyObject_Compare() (and PyErr_Clear() if PyErr_Occurred() returned true). PyErr_Compare() really doesn't expect a pending exception coming in and so *not* clearing the error might break the *next* PyErr_Compare() call. (This doesn't happen typically but PyObject_Compare() can execute arbitrary code, some of which might call PyErr_Occurred() without calling PyErr_Clear() first.) ------------------------------------------------------- Date: 2000-Sep-05 06:05 By: none Comment: Correct! But then, aren't the current "else" if(cmp == 0) clauses risky after PyObject_Compare()? An exception may be set in external code while making Object_Compare() to return 0! Perhaps not in Python source, but in buggy extensions. lookdict() will then overlook this "hit". Patch updated, without "else" clauses and with the 1st char check in string_compare_equal(). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101394&group_id=5470 From noreply@sourceforge.net Tue Sep 5 14:08:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 5 Sep 2000 06:08:22 -0700 Subject: [Patches] [Patch #101394] lookdict optimizations Message-ID: <200009051308.GAA13332@bush.i.sourceforge.net> Patch #101394 has been updated. Project: Category: core (C code) Status: Open Summary: lookdict optimizations Follow-Ups: Date: 2000-Sep-03 21:09 By: marangoz Comment: Let's add a comment, although this has been raised on python-dev. This patch proposes a couple of ideas for optimizing & speeding dict lookups -- not all of them need to be applied though. - clear the eventual errors from Object_Compare only on need (this logic needs to be double-checked once again to see whether it really works) - defer variable initializations after the most common return cases - specialize string_compare() for lookdict_string. The test comparing the first char, before calling memcmp(), can be added too. - inline the first item probe in PyDict_GetItem. This saves a func call for the most common case (common to lookdict & lookdict_string). ------------------------------------------------------- Date: 2000-Sep-04 06:45 By: gvanrossum Comment: Quick comments: we should *always* call PyErr_Occurred() after PyObject_Compare() (and PyErr_Clear() if PyErr_Occurred() returned true). PyErr_Compare() really doesn't expect a pending exception coming in and so *not* clearing the error might break the *next* PyErr_Compare() call. (This doesn't happen typically but PyObject_Compare() can execute arbitrary code, some of which might call PyErr_Occurred() without calling PyErr_Clear() first.) ------------------------------------------------------- Date: 2000-Sep-05 06:05 By: none Comment: Correct! But then, aren't the current "else" if(cmp == 0) clauses risky after PyObject_Compare()? An exception may be set in external code while making Object_Compare() to return 0! Perhaps not in Python source, but in buggy extensions. lookdict() will then overlook this "hit". Patch updated, without "else" clauses and with the 1st char check in string_compare_equal(). ------------------------------------------------------- Date: 2000-Sep-05 06:08 By: marangoz Comment: Argh! These Web interfaces strike again - forgot to login. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101394&group_id=5470 From noreply@sourceforge.net Tue Sep 5 15:07:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 5 Sep 2000 07:07:39 -0700 Subject: [Patches] [Patch #101420] auto-detect libdb Message-ID: <200009051407.HAA12091@delerium.i.sourceforge.net> Patch #101420 has been updated. Project: Category: Build Status: Open Summary: auto-detect libdb Follow-Ups: Date: 2000-Sep-05 07:07 By: montanaro Comment: I'll take this one since I made the original change. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101420&group_id=5470 From noreply@sourceforge.net Tue Sep 5 21:08:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 5 Sep 2000 13:08:15 -0700 Subject: [Patches] [Patch #101423] Fix for 110686: cStringIO.readlines Message-ID: <200009052008.NAA28504@bush.i.sourceforge.net> Patch #101423 has been updated. Project: Category: library Status: Open Summary: Fix for 110686: cStringIO.readlines ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101423&group_id=5470 From noreply@sourceforge.net Tue Sep 5 21:58:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 5 Sep 2000 13:58:32 -0700 Subject: [Patches] [Patch #101424] Fix for 110629: guarantee unique image names Message-ID: <200009052058.NAA27440@delerium.i.sourceforge.net> Patch #101424 has been updated. Project: Category: library Status: Open Summary: Fix for 110629: guarantee unique image names ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101424&group_id=5470 From noreply@sourceforge.net Tue Sep 5 22:41:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 5 Sep 2000 14:41:28 -0700 Subject: [Patches] [Patch #101425] Fix for 110598: support \r in py_compile Message-ID: <200009052141.OAA29128@delerium.i.sourceforge.net> Patch #101425 has been updated. Project: Category: library Status: Open Summary: Fix for 110598: support \r in py_compile ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101425&group_id=5470 From noreply@sourceforge.net Wed Sep 6 07:44:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 5 Sep 2000 23:44:10 -0700 Subject: [Patches] [Patch #101428] typo's in NEWS Message-ID: <200009060644.XAA07651@bush.i.sourceforge.net> Patch #101428 has been updated. Project: Category: None Status: Open Summary: typo's in NEWS ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101428&group_id=5470 From noreply@sourceforge.net Wed Sep 6 14:02:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Sep 2000 06:02:59 -0700 Subject: [Patches] [Patch #101428] typo's in NEWS Message-ID: <200009061302.GAA27977@delerium.i.sourceforge.net> Patch #101428 has been updated. Project: Category: None Status: Closed Summary: typo's in NEWS Follow-Ups: Date: 2000-Sep-06 06:02 By: gvanrossum Comment: Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101428&group_id=5470 From noreply@sourceforge.net Wed Sep 6 21:39:27 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Sep 2000 13:39:27 -0700 Subject: [Patches] [Patch #101433] Fix for 110845: Check struct short and byte ranges Message-ID: <200009062039.NAA12771@delerium.i.sourceforge.net> Patch #101433 has been updated. Project: Category: library Status: Open Summary: Fix for 110845: Check struct short and byte ranges ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101433&group_id=5470 From noreply@sourceforge.net Thu Sep 7 00:44:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Sep 2000 16:44:50 -0700 Subject: [Patches] [Patch #101437] Fix for 110675: GNU pth support Message-ID: <200009062344.QAA12664@bush.i.sourceforge.net> Patch #101437 has been updated. Project: Category: core (C code) Status: Open Summary: Fix for 110675: GNU pth support ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101437&group_id=5470 From noreply@sourceforge.net Thu Sep 7 01:01:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Sep 2000 17:01:31 -0700 Subject: [Patches] [Patch #101437] Fix for 110675: GNU pth support Message-ID: <200009070001.RAA13260@bush.i.sourceforge.net> Patch #101437 has been updated. Project: Category: core (C code) Status: Open Summary: Fix for 110675: GNU pth support Follow-Ups: Date: 2000-Sep-06 17:01 By: adustman Comment: Makes better use of GNU autoconf. configure --with-pth[=DIR] # --with-threads implied Passes test_fork1 and test_thread. Tested with pth-1.3.7. XXX With pth, select() (and others) do not wake up in response to signals. Example: >>> import time >>> time.sleep(10) [hit ctrl-C, no response for 10 seconds] Traceback (most recent call last): File "", line 1, in ? KeyboardInterrupt >>> I have a patch to pth that fixes this that I will try to get incorporated. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101437&group_id=5470 From noreply@sourceforge.net Thu Sep 7 04:40:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Sep 2000 20:40:13 -0700 Subject: [Patches] [Patch #101439] Better syntax for print ( 'print [to file [,]] [(arg ,)*]' ) Message-ID: <200009070340.UAA21077@bush.i.sourceforge.net> Patch #101439 has been updated. Project: Category: core (C code) Status: Open Summary: Better syntax for print ( 'print [to file [,]] [(arg ,)*]' ) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101439&group_id=5470 From noreply@sourceforge.net Thu Sep 7 04:51:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Sep 2000 20:51:36 -0700 Subject: [Patches] [Patch #101398] API doc changes (InPlace-API & And/Or/Xor fixes) Message-ID: <200009070351.UAA21507@bush.i.sourceforge.net> Patch #101398 has been updated. Project: Category: documentation Status: Accepted Summary: API doc changes (InPlace-API & And/Or/Xor fixes) Follow-Ups: Date: 2000-Sep-02 10:08 By: twouters Comment: the API docs state that 'PyNumber_And' and 'PyNumber_Or' are equivalent to 'o1 and o2' and 'o1 or o2' respectively. This is wrong, they are equivalent to 'o1 & o2' and 'o1 | o2', respectively. I'm not sure whether | needs to be escaped or not, in TeX, so I escaped it just in case. ------------------------------------------------------- Date: 2000-Sep-02 10:30 By: twouters Comment: Updated patch, which rewords the PyNumber_And, PyNumber_Or and PyNumber_Xor descriptions to make them slightly more obvious. (note: the use of ``'s and '''s is taken from the old descriptions, there might be a better \TeX{dingus} for it.) ------------------------------------------------------- Date: 2000-Sep-04 04:25 By: twouters Comment: New version that also includes the docs for the new InPlace API calls. Changed patch summary accordingly. This markup was given a cursory test, and it builds proper .ps/.dvi files, but I'm not a TeX-warrior and there might be better ways. I'm also still working on a new ref-section on augmented assignment, which I hope to finish before heading off to Italy tomorrow (but if I don't manage to finish it, I'll mail my almost-finished stuff, to python-dev or to Fred directly.) Tutorial will have to wait until I'm back or for someone else to do it :P ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101398&group_id=5470 From noreply@sourceforge.net Thu Sep 7 04:57:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Sep 2000 20:57:29 -0700 Subject: [Patches] [Patch #101418] More augmented assignment docs Message-ID: <200009070357.UAA21668@bush.i.sourceforge.net> Patch #101418 has been updated. Project: Category: documentation Status: Accepted Summary: More augmented assignment docs Follow-Ups: Date: 2000-Sep-04 13:15 By: twouters Comment: Reference manual docs for augmented assignment. No clue if this actually works, with the \subsection and \indexii things and all, but I did my best ;-P Could still use some crossreferencing, I'm sure. ------------------------------------------------------- Date: 2000-Sep-06 20:57 By: fdrake Comment: Following the \indexii line, please add this line: \index{statement!assignment, augmented} Then check it in. Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101418&group_id=5470 From noreply@sourceforge.net Thu Sep 7 04:58:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Sep 2000 20:58:57 -0700 Subject: [Patches] [Patch #101394] lookdict optimizations Message-ID: <200009070358.UAA21775@bush.i.sourceforge.net> Patch #101394 has been updated. Project: Category: core (C code) Status: Open Summary: lookdict optimizations Follow-Ups: Date: 2000-Sep-03 21:09 By: marangoz Comment: Let's add a comment, although this has been raised on python-dev. This patch proposes a couple of ideas for optimizing & speeding dict lookups -- not all of them need to be applied though. - clear the eventual errors from Object_Compare only on need (this logic needs to be double-checked once again to see whether it really works) - defer variable initializations after the most common return cases - specialize string_compare() for lookdict_string. The test comparing the first char, before calling memcmp(), can be added too. - inline the first item probe in PyDict_GetItem. This saves a func call for the most common case (common to lookdict & lookdict_string). ------------------------------------------------------- Date: 2000-Sep-04 06:45 By: gvanrossum Comment: Quick comments: we should *always* call PyErr_Occurred() after PyObject_Compare() (and PyErr_Clear() if PyErr_Occurred() returned true). PyErr_Compare() really doesn't expect a pending exception coming in and so *not* clearing the error might break the *next* PyErr_Compare() call. (This doesn't happen typically but PyObject_Compare() can execute arbitrary code, some of which might call PyErr_Occurred() without calling PyErr_Clear() first.) ------------------------------------------------------- Date: 2000-Sep-05 06:05 By: none Comment: Correct! But then, aren't the current "else" if(cmp == 0) clauses risky after PyObject_Compare()? An exception may be set in external code while making Object_Compare() to return 0! Perhaps not in Python source, but in buggy extensions. lookdict() will then overlook this "hit". Patch updated, without "else" clauses and with the 1st char check in string_compare_equal(). ------------------------------------------------------- Date: 2000-Sep-05 06:08 By: marangoz Comment: Argh! These Web interfaces strike again - forgot to login. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101394&group_id=5470 From noreply@sourceforge.net Thu Sep 7 05:08:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Sep 2000 21:08:08 -0700 Subject: [Patches] [Patch #101424] Fix for 110629: guarantee unique image names Message-ID: <200009070408.VAA22097@bush.i.sourceforge.net> Patch #101424 has been updated. Project: Category: library Status: Accepted Summary: Fix for 110629: guarantee unique image names Follow-Ups: Date: 2000-Sep-06 21:08 By: fdrake Comment: Check it in & close the bug report! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101424&group_id=5470 From noreply@sourceforge.net Thu Sep 7 05:17:51 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Sep 2000 21:17:51 -0700 Subject: [Patches] [Patch #101439] Better syntax for print ( 'print [to file [,]] [(arg ,)*]' ) Message-ID: <200009070417.VAA22344@bush.i.sourceforge.net> Patch #101439 has been updated. Project: Category: core (C code) Status: Open Summary: Better syntax for print ( 'print [to file [,]] [(arg ,)*]' ) Follow-Ups: Date: 2000-Sep-06 21:17 By: williamc Comment: oh ugh this made 'to' a keyword... coulda sworn I fixed that... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101439&group_id=5470 From noreply@sourceforge.net Thu Sep 7 05:35:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 6 Sep 2000 21:35:38 -0700 Subject: [Patches] [Patch #101439] Better syntax for print ( 'print [to file [,]] [(arg ,)*]' ) Message-ID: <200009070435.VAA29568@delerium.i.sourceforge.net> Patch #101439 has been updated. Project: Category: core (C code) Status: Open Summary: Better syntax for print ( 'print [to file [,]] [(arg ,)*]' ) Follow-Ups: Date: 2000-Sep-06 21:17 By: williamc Comment: oh ugh this made 'to' a keyword... coulda sworn I fixed that... ------------------------------------------------------- Date: 2000-Sep-06 21:35 By: williamc Comment: Just go ahead and close this for the time being. I will be resubmitting when I get my CVS working copy straightened out. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101439&group_id=5470 From noreply@sourceforge.net Thu Sep 7 14:20:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 7 Sep 2000 06:20:29 -0700 Subject: [Patches] [Patch #101420] auto-detect libdb Message-ID: <200009071320.GAA15389@delerium.i.sourceforge.net> Patch #101420 has been updated. Project: Category: Build Status: Accepted Summary: auto-detect libdb Follow-Ups: Date: 2000-Sep-05 07:07 By: montanaro Comment: I'll take this one since I made the original change. ------------------------------------------------------- Date: 2000-Sep-07 06:20 By: montanaro Comment: This looks good to me. I made a slight change to the order of the tests and had Thomas check it out. He tried it and said it looked fine to him. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101420&group_id=5470 From noreply@sourceforge.net Thu Sep 7 15:09:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 7 Sep 2000 07:09:39 -0700 Subject: [Patches] [Patch #101439] Better syntax for print ( 'print [to file [,]] [(arg ,)*]' ) Message-ID: <200009071409.HAA10084@bush.i.sourceforge.net> Patch #101439 has been updated. Project: Category: core (C code) Status: Rejected Summary: Better syntax for print ( 'print [to file [,]] [(arg ,)*]' ) Follow-Ups: Date: 2000-Sep-06 21:17 By: williamc Comment: oh ugh this made 'to' a keyword... coulda sworn I fixed that... ------------------------------------------------------- Date: 2000-Sep-06 21:35 By: williamc Comment: Just go ahead and close this for the time being. I will be resubmitting when I get my CVS working copy straightened out. ------------------------------------------------------- Date: 2000-Sep-07 07:09 By: gvanrossum Comment: Forget it. See PEP 0214 for why 'to' is a bad idea. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101439&group_id=5470 From noreply@sourceforge.net Thu Sep 7 15:37:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 7 Sep 2000 07:37:08 -0700 Subject: [Patches] [Patch #101447] Fix for 113704: Update asyncore/asynchat Message-ID: <200009071437.HAA11061@bush.i.sourceforge.net> Patch #101447 has been updated. Project: Category: library Status: Open Summary: Fix for 113704: Update asyncore/asynchat ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101447&group_id=5470 From noreply@sourceforge.net Thu Sep 7 16:43:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 7 Sep 2000 08:43:17 -0700 Subject: [Patches] [Patch #101447] Fix for 113704: Update asyncore/asynchat Message-ID: <200009071543.IAA20720@delerium.i.sourceforge.net> Patch #101447 has been updated. Project: Category: library Status: Open Summary: Fix for 113704: Update asyncore/asynchat Follow-Ups: Date: 2000-Sep-07 08:43 By: adustman Comment: I just browsed through this patch, and noticed at the end: import regex This is in asynchat.py. Shouldn't we update this for re? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101447&group_id=5470 From noreply@sourceforge.net Thu Sep 7 16:58:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 7 Sep 2000 08:58:23 -0700 Subject: [Patches] [Patch #101447] Fix for 113704: Update asyncore/asynchat Message-ID: <200009071558.IAA14163@bush.i.sourceforge.net> Patch #101447 has been updated. Project: Category: library Status: Open Summary: Fix for 113704: Update asyncore/asynchat Follow-Ups: Date: 2000-Sep-07 08:43 By: adustman Comment: I just browsed through this patch, and noticed at the end: import regex This is in asynchat.py. Shouldn't we update this for re? ------------------------------------------------------- Date: 2000-Sep-07 08:58 By: akuchling Comment: Probably, but that would be more work and should really be in a separate patch sent to Sam Rushing, original author of the code. For now I think we should just resync with Sam's code, because it really complicates life for people distributing Zope. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101447&group_id=5470 From noreply@sourceforge.net Fri Sep 8 01:14:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 7 Sep 2000 17:14:13 -0700 Subject: [Patches] [Patch #100947] increase control and default size of pdb traceback display Message-ID: <200009080014.RAA07789@delerium.i.sourceforge.net> Patch #100947 has been updated. Project: Category: library Status: Postponed Summary: increase control and default size of pdb traceback display Follow-Ups: Date: 2000-Aug-13 20:15 By: nowonder Comment: There is a detailed description in the patch. ------------------------------------------------------- Date: 2000-Aug-15 10:55 By: tim_one Comment: Reassigned to Guido in Jeremy's absence, cuz I never use pdb but know Guido has at least once . Please review or pass on to someone else. ------------------------------------------------------- Date: 2000-Aug-17 12:36 By: gvanrossum Comment: I like the idea fine, but the command name "scaletb" sucks. Once a better name is coined Ken should get checkin permissions if he doesn't already have them, so he can check it in. (Isn't it ironic that Ken, who enjoys naming debates so much, came up with a sucky name? :-) Possibly a better name could include "control" (or an abbreviation) instead of "scale"? ------------------------------------------------------- Date: 2000-Aug-21 16:59 By: tim_one Comment: Ken, are you going to repsond to Guido's comments? And do you want developer privileges? ------------------------------------------------------- Date: 2000-Aug-27 09:57 By: klm Comment: Sorry about not responding more promptly. Actually, i got the email for guido's patch comment, and wasn't sure who to contact about getting checkin privileges, so was waiting for a moment to look around a bit to track that down and think things through. It so happens (1) i didn't get the moment until this morning (!), and (2) i must have missed tim's subsequent comment in my email box, because this is the first i saw of it. I do seem to have cvs ssh access, now, and have an alternate name to suggest. I'd be happy to arrive at some agreement on a name and then check in the changes. My current suggestion is 'limit_tb', with no abbreviation. I think this name is a lot more self-evident than scaletb, and a lot more specific than something like 'control_tb'. I can see objections to this, and am open to other suggestions. (If you insist on 'control_tb' or somesuch, fine.) Though this is Just A Name, there are some complications arriving at a name that fits well with the pdb commands. First, none of the other pdb command names are very long, so while "limit_traceback" would be most clear, it would be out of place. And cumbersome. Inclusion of an underscore in a pdb command name is, itself, unprecedented, but that helps avoid confusion with the "tb" of 'tbreak' (where "tb" => "temporary break"). Perhaps the "tb" collision is enough reason to spell out "traceback" - but incongruous and cumbersome, see above. Perhaps the most comprehensive solution would be to have a pdb "set" command, to set operational options, and then have a "set traceback_limit". That seems much too elaborate for a single option. It also seems like overkill even for several options, if there's no persistence to the pdb configuration - too much for settings that only last for a python session. While there may or may not be good reasons to have a persistent mechanism, i think the limit_tb command would be quite useful without it - people can enlarge the tb size once they see it's necessary, and reevoke it. So i'm for 'limit_tb', but open to other suggestions, willing to accept an edict if that means i can just check this in (or try another approach). (I think i'm set to do the checkin - i assume my addition to the python project developers roster means i have the privileges, and i've applied the patch to an ssh checkout, ready and sort of eager to try the checkin...) Ken ------------------------------------------------------- Date: 2000-Aug-31 14:36 By: jhylton Comment: Ken has disappeared ------------------------------------------------------- Date: 2000-Sep-07 17:14 By: klm Comment: Here's a new patch using "limit_tb" instead of "scaletb" as the name. I also realize that the changes to repr - presentation limits added as parameters on __init__, plus a "multiplication factor" to make it easy to change from standard limits with one easy value - ought to be documented in the repr standard library docs. I'll pursue that, if necessary, but wanted to see if this new name, and the rest of the patch, passes muster. As jeremy suggested, i will setting the "assigned to" to guido, so he judge it. (Except i don't see how to reassign - perhaps that comes next, after submitting this?? Murgh.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100947&group_id=5470 From noreply@sourceforge.net Fri Sep 8 02:02:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 7 Sep 2000 18:02:15 -0700 Subject: [Patches] [Patch #100947] increase control and default size of pdb traceback display Message-ID: <200009080102.SAA09319@delerium.i.sourceforge.net> Patch #100947 has been updated. Project: Category: library Status: Postponed Summary: increase control and default size of pdb traceback display Follow-Ups: Date: 2000-Aug-13 20:15 By: nowonder Comment: There is a detailed description in the patch. ------------------------------------------------------- Date: 2000-Aug-15 10:55 By: tim_one Comment: Reassigned to Guido in Jeremy's absence, cuz I never use pdb but know Guido has at least once . Please review or pass on to someone else. ------------------------------------------------------- Date: 2000-Aug-17 12:36 By: gvanrossum Comment: I like the idea fine, but the command name "scaletb" sucks. Once a better name is coined Ken should get checkin permissions if he doesn't already have them, so he can check it in. (Isn't it ironic that Ken, who enjoys naming debates so much, came up with a sucky name? :-) Possibly a better name could include "control" (or an abbreviation) instead of "scale"? ------------------------------------------------------- Date: 2000-Aug-21 16:59 By: tim_one Comment: Ken, are you going to repsond to Guido's comments? And do you want developer privileges? ------------------------------------------------------- Date: 2000-Aug-27 09:57 By: klm Comment: Sorry about not responding more promptly. Actually, i got the email for guido's patch comment, and wasn't sure who to contact about getting checkin privileges, so was waiting for a moment to look around a bit to track that down and think things through. It so happens (1) i didn't get the moment until this morning (!), and (2) i must have missed tim's subsequent comment in my email box, because this is the first i saw of it. I do seem to have cvs ssh access, now, and have an alternate name to suggest. I'd be happy to arrive at some agreement on a name and then check in the changes. My current suggestion is 'limit_tb', with no abbreviation. I think this name is a lot more self-evident than scaletb, and a lot more specific than something like 'control_tb'. I can see objections to this, and am open to other suggestions. (If you insist on 'control_tb' or somesuch, fine.) Though this is Just A Name, there are some complications arriving at a name that fits well with the pdb commands. First, none of the other pdb command names are very long, so while "limit_traceback" would be most clear, it would be out of place. And cumbersome. Inclusion of an underscore in a pdb command name is, itself, unprecedented, but that helps avoid confusion with the "tb" of 'tbreak' (where "tb" => "temporary break"). Perhaps the "tb" collision is enough reason to spell out "traceback" - but incongruous and cumbersome, see above. Perhaps the most comprehensive solution would be to have a pdb "set" command, to set operational options, and then have a "set traceback_limit". That seems much too elaborate for a single option. It also seems like overkill even for several options, if there's no persistence to the pdb configuration - too much for settings that only last for a python session. While there may or may not be good reasons to have a persistent mechanism, i think the limit_tb command would be quite useful without it - people can enlarge the tb size once they see it's necessary, and reevoke it. So i'm for 'limit_tb', but open to other suggestions, willing to accept an edict if that means i can just check this in (or try another approach). (I think i'm set to do the checkin - i assume my addition to the python project developers roster means i have the privileges, and i've applied the patch to an ssh checkout, ready and sort of eager to try the checkin...) Ken ------------------------------------------------------- Date: 2000-Aug-31 14:36 By: jhylton Comment: Ken has disappeared ------------------------------------------------------- Date: 2000-Sep-07 17:14 By: klm Comment: Here's a new patch using "limit_tb" instead of "scaletb" as the name. I also realize that the changes to repr - presentation limits added as parameters on __init__, plus a "multiplication factor" to make it easy to change from standard limits with one easy value - ought to be documented in the repr standard library docs. I'll pursue that, if necessary, but wanted to see if this new name, and the rest of the patch, passes muster. As jeremy suggested, i will setting the "assigned to" to guido, so he judge it. (Except i don't see how to reassign - perhaps that comes next, after submitting this?? Murgh.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100947&group_id=5470 From noreply@sourceforge.net Fri Sep 8 03:17:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 7 Sep 2000 19:17:35 -0700 Subject: [Patches] [Patch #101420] auto-detect libdb Message-ID: <200009080217.TAA05278@bush.i.sourceforge.net> Patch #101420 has been updated. Project: Category: Build Status: Closed Summary: auto-detect libdb Follow-Ups: Date: 2000-Sep-05 07:07 By: montanaro Comment: I'll take this one since I made the original change. ------------------------------------------------------- Date: 2000-Sep-07 06:20 By: montanaro Comment: This looks good to me. I made a slight change to the order of the tests and had Thomas check it out. He tried it and said it looked fine to him. ------------------------------------------------------- Date: 2000-Sep-07 19:17 By: montanaro Comment: checked in changes to configure.in, configure and Modules/Setup.config.in ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101420&group_id=5470 From noreply@sourceforge.net Fri Sep 8 14:58:26 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 8 Sep 2000 06:58:26 -0700 Subject: [Patches] [Patch #101447] Fix for 113704: Update asyncore/asynchat Message-ID: <200009081358.GAA29450@bush.i.sourceforge.net> Patch #101447 has been updated. Project: Category: library Status: Open Summary: Fix for 113704: Update asyncore/asynchat Follow-Ups: Date: 2000-Sep-07 08:43 By: adustman Comment: I just browsed through this patch, and noticed at the end: import regex This is in asynchat.py. Shouldn't we update this for re? ------------------------------------------------------- Date: 2000-Sep-07 08:58 By: akuchling Comment: Probably, but that would be more work and should really be in a separate patch sent to Sam Rushing, original author of the code. For now I think we should just resync with Sam's code, because it really complicates life for people distributing Zope. ------------------------------------------------------- Date: 2000-Sep-08 06:58 By: akuchling Comment: Updated the patch. Sam Rushing has accepted the docstring changes, so the files are now identical to Sam's except for removing the $$ surrounding the Id CVS tag. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101447&group_id=5470 From noreply@sourceforge.net Fri Sep 8 17:29:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 8 Sep 2000 09:29:03 -0700 Subject: [Patches] [Patch #101424] Fix for 110629: guarantee unique image names Message-ID: <200009081629.JAA02680@bush.i.sourceforge.net> Patch #101424 has been updated. Project: Category: library Status: Closed Summary: Fix for 110629: guarantee unique image names Follow-Ups: Date: 2000-Sep-06 21:08 By: fdrake Comment: Check it in & close the bug report! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101424&group_id=5470 From noreply@sourceforge.net Fri Sep 8 21:40:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 8 Sep 2000 13:40:16 -0700 Subject: [Patches] [Patch #101454] Add Unicode support to "exec" and "eval()" Message-ID: <200009082040.NAA17780@delerium.i.sourceforge.net> Patch #101454 has been updated. Project: Category: core (C code) Status: Open Summary: Add Unicode support to "exec" and "eval()" ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101454&group_id=5470 From noreply@sourceforge.net Fri Sep 8 21:53:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 8 Sep 2000 13:53:35 -0700 Subject: [Patches] [Patch #101454] Add Unicode support to "exec" and "eval()" Message-ID: <200009082053.NAA18304@delerium.i.sourceforge.net> Patch #101454 has been updated. Project: Category: core (C code) Status: Open Summary: Add Unicode support to "exec" and "eval()" Follow-Ups: Date: 2000-Sep-08 13:53 By: lemburg Comment: This patch adds support for Unicode objects to exec and eval(). Unicode objects are converted to default encoded strings prior to processing them with the usual logic. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101454&group_id=5470 From noreply@sourceforge.net Fri Sep 8 22:45:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 8 Sep 2000 14:45:57 -0700 Subject: [Patches] [Patch #101458] Adding Unicode support to get|set|hasattr() Message-ID: <200009082145.OAA14438@bush.i.sourceforge.net> Patch #101458 has been updated. Project: Category: None Status: Open Summary: Adding Unicode support to get|set|hasattr() ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101458&group_id=5470 From noreply@sourceforge.net Fri Sep 8 22:48:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 8 Sep 2000 14:48:34 -0700 Subject: [Patches] [Patch #101458] Adding Unicode support to get|set|hasattr() Message-ID: <200009082148.OAA14589@bush.i.sourceforge.net> Patch #101458 has been updated. Project: Category: None Status: Open Summary: Adding Unicode support to get|set|hasattr() Follow-Ups: Date: 2000-Sep-08 14:48 By: lemburg Comment: This patch add Unicode support to the PyObject_SetAttr() and PyObject_GetAttr() APIs which are used by the mentioned builtin functions to set or query attributes. While implementing the patch I found that all current tp_getattro and tp_setattro implementations (classes, instances, methods) expect to find string objects as argument and don't even check for this. The patch realizes this behaviour by only accepting string or Unicode objects as name parameter to the two C APIs. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101458&group_id=5470 From noreply@sourceforge.net Fri Sep 8 22:50:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 8 Sep 2000 14:50:08 -0700 Subject: [Patches] [Patch #101458] Adding Unicode support to get|set|hasattr() Message-ID: <200009082150.OAA14618@bush.i.sourceforge.net> Patch #101458 has been updated. Project: Category: core (C code) Status: Open Summary: Adding Unicode support to get|set|hasattr() Follow-Ups: Date: 2000-Sep-08 14:48 By: lemburg Comment: This patch add Unicode support to the PyObject_SetAttr() and PyObject_GetAttr() APIs which are used by the mentioned builtin functions to set or query attributes. While implementing the patch I found that all current tp_getattro and tp_setattro implementations (classes, instances, methods) expect to find string objects as argument and don't even check for this. The patch realizes this behaviour by only accepting string or Unicode objects as name parameter to the two C APIs. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101458&group_id=5470 From noreply@sourceforge.net Sat Sep 9 07:11:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 8 Sep 2000 23:11:07 -0700 Subject: [Patches] [Patch #101412] add gc.DEBUG_SAVEALL option, gc_str fix Message-ID: <200009090611.XAA31413@bush.i.sourceforge.net> Patch #101412 has been updated. Project: Category: core (C code) Status: Open Summary: add gc.DEBUG_SAVEALL option, gc_str fix Follow-Ups: Date: 2000-Sep-03 20:13 By: marangoz Comment: Looks good. I approve the str fix. One nit: "else" clauses usually go to a new line in the Python source. Make it "else if" on a new line. Questions: - DEBUG_LEAK now includes SAVEALL. The regression test suite sets DEBUG_LEAK by default. It used to report a bunch of objects during test_gc. Now it will collect the detected cycles in the suite. Should regrtest.py report them somehow? - After the regression test, gc.garbage contains an A instance and an empty list. I think they're created by test_gc. Can't they be cleared? We can assign gc.garbage = [], but this doesn't clear anything. - test_gc/test_saveall has gc.set_debug(0), followed immediately by gc.set_debug(gc.DEBUG_SAVEALL). Is this on purpose or is it a typo? BTW, I don't quite understand why this function does what it does... Could you elaborate on it? ------------------------------------------------------- Date: 2000-Sep-04 07:05 By: nascheme Comment: - regrtest will print the repr of cyclic garbage found if -l option is specified and -q is not - put else on newline in accordance with Python style - constrain debugging options during test_gc (don't enabled DEBUG_LEAK) - fix test_gc to remove garbage from gc.garbage ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101412&group_id=5470 From noreply@sourceforge.net Tue Sep 12 21:27:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Sep 2000 13:27:45 -0700 Subject: [Patches] [Patch #101398] API doc changes (InPlace-API & And/Or/Xor fixes) Message-ID: <200009122027.NAA06151@bush.i.sourceforge.net> Patch #101398 has been updated. Project: Category: documentation Status: Closed Summary: API doc changes (InPlace-API & And/Or/Xor fixes) Follow-Ups: Date: 2000-Sep-02 10:08 By: twouters Comment: the API docs state that 'PyNumber_And' and 'PyNumber_Or' are equivalent to 'o1 and o2' and 'o1 or o2' respectively. This is wrong, they are equivalent to 'o1 & o2' and 'o1 | o2', respectively. I'm not sure whether | needs to be escaped or not, in TeX, so I escaped it just in case. ------------------------------------------------------- Date: 2000-Sep-02 10:30 By: twouters Comment: Updated patch, which rewords the PyNumber_And, PyNumber_Or and PyNumber_Xor descriptions to make them slightly more obvious. (note: the use of ``'s and '''s is taken from the old descriptions, there might be a better \TeX{dingus} for it.) ------------------------------------------------------- Date: 2000-Sep-04 04:25 By: twouters Comment: New version that also includes the docs for the new InPlace API calls. Changed patch summary accordingly. This markup was given a cursory test, and it builds proper .ps/.dvi files, but I'm not a TeX-warrior and there might be better ways. I'm also still working on a new ref-section on augmented assignment, which I hope to finish before heading off to Italy tomorrow (but if I don't manage to finish it, I'll mail my almost-finished stuff, to python-dev or to Fred directly.) Tutorial will have to wait until I'm back or for someone else to do it :P ------------------------------------------------------- Date: 2000-Sep-12 13:27 By: fdrake Comment: Checked in by me since Thomas is away. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101398&group_id=5470 From noreply@sourceforge.net Tue Sep 12 21:32:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Sep 2000 13:32:41 -0700 Subject: [Patches] [Patch #101418] More augmented assignment docs Message-ID: <200009122032.NAA06376@bush.i.sourceforge.net> Patch #101418 has been updated. Project: Category: documentation Status: Closed Summary: More augmented assignment docs Follow-Ups: Date: 2000-Sep-04 13:15 By: twouters Comment: Reference manual docs for augmented assignment. No clue if this actually works, with the \subsection and \indexii things and all, but I did my best ;-P Could still use some crossreferencing, I'm sure. ------------------------------------------------------- Date: 2000-Sep-06 20:57 By: fdrake Comment: Following the \indexii line, please add this line: \index{statement!assignment, augmented} Then check it in. Thanks! ------------------------------------------------------- Date: 2000-Sep-12 13:32 By: fdrake Comment: Checked in by me since Thomas is away. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101418&group_id=5470 From noreply@sourceforge.net Tue Sep 12 23:25:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Sep 2000 15:25:09 -0700 Subject: [Patches] [Patch #101486] Unexpected Evaluation of Expressions from Pickle Patch Message-ID: <200009122225.PAA10604@bush.i.sourceforge.net> Patch #101486 has been updated. Project: Category: Modules Status: Open Summary: Unexpected Evaluation of Expressions from Pickle Patch ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101486&group_id=5470 From noreply@sourceforge.net Tue Sep 12 23:22:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Sep 2000 15:22:11 -0700 Subject: [Patches] [Patch #101485] Patch to test sendmail virtual domain gid's for bug #114235 Message-ID: <200009122222.PAA27393@delerium.i.sourceforge.net> Patch #101485 has been updated. Project: Category: None Status: Open Summary: Patch to test sendmail virtual domain gid's for bug #114235 Follow-Ups: Date: 2000-Sep-12 15:22 By: bwarsaw Comment: See SF bug #114235 for what this program tests. This patch (and the bug) really have nothing to do with Python, I believe. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101485&group_id=5470 From noreply@sourceforge.net Tue Sep 12 23:20:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Sep 2000 15:20:46 -0700 Subject: [Patches] [Patch #101485] Patch to test sendmail virtual domain gid's for bug #114235 Message-ID: <200009122220.PAA27345@delerium.i.sourceforge.net> Patch #101485 has been updated. Project: Category: None Status: Open Summary: Patch to test sendmail virtual domain gid's for bug #114235 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101485&group_id=5470 From noreply@sourceforge.net Wed Sep 13 08:36:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Sep 2000 00:36:46 -0700 Subject: [Patches] [Patch #101495] mailbox.py broken for Maildir Message-ID: <200009130736.AAA18832@delerium.i.sourceforge.net> Patch #101495 has been updated. Project: Category: library Status: Open Summary: mailbox.py broken for Maildir ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101495&group_id=5470 From noreply@sourceforge.net Wed Sep 13 12:04:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Sep 2000 04:04:19 -0700 Subject: [Patches] [Patch #101472] Fix for 110842: Add several dl.RTLD_ constants Message-ID: <200009131104.EAA06917@bush.i.sourceforge.net> Patch #101472 has been updated. Project: Category: library Status: Closed Summary: Fix for 110842: Add several dl.RTLD_ constants Follow-Ups: Date: 2000-Sep-13 04:04 By: gvanrossum Comment: Checked in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101472&group_id=5470 From noreply@sourceforge.net Wed Sep 13 12:06:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Sep 2000 04:06:11 -0700 Subject: [Patches] [Patch #101472] Fix for 110842: Add several dl.RTLD_ constants Message-ID: <200009131106.EAA06956@bush.i.sourceforge.net> Patch #101472 has been updated. Project: Category: library Status: Accepted Summary: Fix for 110842: Add several dl.RTLD_ constants Follow-Ups: Date: 2000-Sep-13 04:04 By: gvanrossum Comment: Checked in. ------------------------------------------------------- Date: 2000-Sep-13 04:06 By: gvanrossum Comment: Please check it in yourself. (Sorry for the misleading comment before.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101472&group_id=5470 From noreply@sourceforge.net Wed Sep 13 13:05:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Sep 2000 05:05:59 -0700 Subject: [Patches] [Patch #101496] Support switches -h and -V (help & version) Message-ID: <200009131205.FAA28445@delerium.i.sourceforge.net> Patch #101496 has been updated. Project: Category: core (C code) Status: Open Summary: Support switches -h and -V (help & version) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101496&group_id=5470 From noreply@sourceforge.net Wed Sep 13 17:28:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Sep 2000 09:28:39 -0700 Subject: [Patches] [Patch #101472] Fix for 110842: Add several dl.RTLD_ constants Message-ID: <200009131628.JAA19946@bush.i.sourceforge.net> Patch #101472 has been updated. Project: Category: library Status: Closed Summary: Fix for 110842: Add several dl.RTLD_ constants Follow-Ups: Date: 2000-Sep-13 04:04 By: gvanrossum Comment: Checked in. ------------------------------------------------------- Date: 2000-Sep-13 04:06 By: gvanrossum Comment: Please check it in yourself. (Sorry for the misleading comment before.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101472&group_id=5470 From noreply@sourceforge.net Thu Sep 14 15:01:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 07:01:49 -0700 Subject: [Patches] [Patch #101507] add 'punctuation' and 'printable' consts. to stropmodule.c Message-ID: <200009141401.HAA02624@bush.i.sourceforge.net> Patch #101507 has been updated. Project: Category: core (C code) Status: Open Summary: add 'punctuation' and 'printable' consts. to stropmodule.c ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101507&group_id=5470 From noreply@sourceforge.net Thu Sep 14 15:02:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 07:02:02 -0700 Subject: [Patches] [Patch #101508] add 'punctuation' and 'printable' consts. to stropmodule.c Message-ID: <200009141402.HAA02644@bush.i.sourceforge.net> Patch #101508 has been updated. Project: Category: core (C code) Status: Open Summary: add 'punctuation' and 'printable' consts. to stropmodule.c ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101508&group_id=5470 From noreply@sourceforge.net Thu Sep 14 15:06:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 07:06:40 -0700 Subject: [Patches] [Patch #101508] add 'punctuation' and 'printable' consts. to stropmodule.c Message-ID: <200009141406.HAA21410@delerium.i.sourceforge.net> Patch #101508 has been updated. Project: Category: core (C code) Status: Deleted Summary: add 'punctuation' and 'printable' consts. to stropmodule.c Follow-Ups: Date: 2000-Sep-14 07:06 By: fdrake Comment: This is a duplicate of #101507; deleted. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101508&group_id=5470 From noreply@sourceforge.net Thu Sep 14 15:08:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 07:08:07 -0700 Subject: [Patches] [Patch #101495] mailbox.py broken for Maildir Message-ID: <200009141408.HAA21438@delerium.i.sourceforge.net> Patch #101495 has been updated. Project: Category: library Status: Deleted Summary: mailbox.py broken for Maildir Follow-Ups: Date: 2000-Sep-14 07:08 By: fdrake Comment: This is a duplicate for #101483; deleted. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101495&group_id=5470 From noreply@sourceforge.net Thu Sep 14 15:09:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 07:09:29 -0700 Subject: [Patches] [Patch #101477] Fixes of ReadStream.readline() in UTF-16 and -LE codecs Message-ID: <200009141409.HAA21570@delerium.i.sourceforge.net> Patch #101477 has been updated. Project: Category: library Status: Open Summary: Fixes of ReadStream.readline() in UTF-16 and -LE codecs Follow-Ups: Date: 2000-Sep-14 07:09 By: fdrake Comment: Marc-Andre, please review this & decide what should happen next. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101477&group_id=5470 From noreply@sourceforge.net Thu Sep 14 15:11:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 07:11:21 -0700 Subject: [Patches] [Patch #101483] mailbox.py broken for Maildir Message-ID: <200009141411.HAA21621@delerium.i.sourceforge.net> Patch #101483 has been updated. Project: Category: library Status: Open Summary: mailbox.py broken for Maildir ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101483&group_id=5470 From noreply@sourceforge.net Thu Sep 14 15:15:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 07:15:44 -0700 Subject: [Patches] [Patch #101507] add 'punctuation' and 'printable' consts. to stropmodule.c Message-ID: <200009141415.HAA21811@delerium.i.sourceforge.net> Patch #101507 has been updated. Project: Category: core (C code) Status: Open Summary: add 'punctuation' and 'printable' consts. to stropmodule.c Follow-Ups: Date: 2000-Sep-14 07:15 By: fdrake Comment: Why not just define these as constants in string.py? That would be more usable since strop is not necessarily available, and can be considered an implementation detail at best. Also, note that ispunct() and isprint() are available in the curses.ascii module. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101507&group_id=5470 From noreply@sourceforge.net Thu Sep 14 15:18:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 07:18:28 -0700 Subject: [Patches] [Patch #101496] Support switches -h and -V (help & version) Message-ID: <200009141418.HAA21969@delerium.i.sourceforge.net> Patch #101496 has been updated. Project: Category: core (C code) Status: Accepted Summary: Support switches -h and -V (help & version) Follow-Ups: Date: 2000-Sep-14 07:18 By: fdrake Comment: This looks good to me; fix Misc/python.man as well, then check it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101496&group_id=5470 From noreply@sourceforge.net Thu Sep 14 15:45:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 07:45:25 -0700 Subject: [Patches] [Patch #101483] mailbox.py broken for Maildir Message-ID: <200009141445.HAA22988@delerium.i.sourceforge.net> Patch #101483 has been updated. Project: Category: library Status: Closed Summary: mailbox.py broken for Maildir Follow-Ups: Date: 2000-Sep-14 07:45 By: fdrake Comment: Checked in as mailbox.py revision 1.23; thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101483&group_id=5470 From noreply@sourceforge.net Thu Sep 14 17:26:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 09:26:04 -0700 Subject: [Patches] [Patch #101394] lookdict optimizations Message-ID: <200009141626.JAA08377@bush.i.sourceforge.net> Patch #101394 has been updated. Project: Category: core (C code) Status: Open Summary: lookdict optimizations Follow-Ups: Date: 2000-Sep-03 21:09 By: marangoz Comment: Let's add a comment, although this has been raised on python-dev. This patch proposes a couple of ideas for optimizing & speeding dict lookups -- not all of them need to be applied though. - clear the eventual errors from Object_Compare only on need (this logic needs to be double-checked once again to see whether it really works) - defer variable initializations after the most common return cases - specialize string_compare() for lookdict_string. The test comparing the first char, before calling memcmp(), can be added too. - inline the first item probe in PyDict_GetItem. This saves a func call for the most common case (common to lookdict & lookdict_string). ------------------------------------------------------- Date: 2000-Sep-04 06:45 By: gvanrossum Comment: Quick comments: we should *always* call PyErr_Occurred() after PyObject_Compare() (and PyErr_Clear() if PyErr_Occurred() returned true). PyErr_Compare() really doesn't expect a pending exception coming in and so *not* clearing the error might break the *next* PyErr_Compare() call. (This doesn't happen typically but PyObject_Compare() can execute arbitrary code, some of which might call PyErr_Occurred() without calling PyErr_Clear() first.) ------------------------------------------------------- Date: 2000-Sep-05 06:05 By: none Comment: Correct! But then, aren't the current "else" if(cmp == 0) clauses risky after PyObject_Compare()? An exception may be set in external code while making Object_Compare() to return 0! Perhaps not in Python source, but in buggy extensions. lookdict() will then overlook this "hit". Patch updated, without "else" clauses and with the 1st char check in string_compare_equal(). ------------------------------------------------------- Date: 2000-Sep-05 06:08 By: marangoz Comment: Argh! These Web interfaces strike again - forgot to login. ------------------------------------------------------- Date: 2000-Sep-14 09:26 By: fdrake Comment: Revised patch: Instead of defining a function to do the fast string comparison, use a macro, but let it use the documented string object API (PyString_GET_SIZE(), PyString_AS_STRING()) instead of breaking the encapsulation in the code. This avoids all function calls to do the string compare, except memcmp() (which good compilers can inline anyway). Vladimir, take a look at this; if you're happy, I'm happy, and you can check it in. Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101394&group_id=5470 From noreply@sourceforge.net Thu Sep 14 17:40:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 09:40:32 -0700 Subject: [Patches] [Patch #101507] add 'punctuation' and 'printable' consts. to stropmodule.c Message-ID: <200009141640.JAA08948@bush.i.sourceforge.net> Patch #101507 has been updated. Project: Category: core (C code) Status: Open Summary: add 'punctuation' and 'printable' consts. to stropmodule.c Follow-Ups: Date: 2000-Sep-14 07:15 By: fdrake Comment: Why not just define these as constants in string.py? That would be more usable since strop is not necessarily available, and can be considered an implementation detail at best. Also, note that ispunct() and isprint() are available in the curses.ascii module. ------------------------------------------------------- Date: 2000-Sep-14 09:40 By: fdrake Comment: Response from Richard Mortier: Ah -- this was originally generated because I wanted to use it in Python 1.5.2 -- didn't realise later versions had curses.ascii Not defining them in string.py was because I wanted the behaviour of isprint() (in particular). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101507&group_id=5470 From noreply@sourceforge.net Thu Sep 14 17:43:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 09:43:02 -0700 Subject: [Patches] [Patch #101507] add 'punctuation' and 'printable' consts. to stropmodule.c Message-ID: <200009141643.JAA09014@bush.i.sourceforge.net> Patch #101507 has been updated. Project: Category: core (C code) Status: Open Summary: add 'punctuation' and 'printable' consts. to stropmodule.c Follow-Ups: Date: 2000-Sep-14 07:15 By: fdrake Comment: Why not just define these as constants in string.py? That would be more usable since strop is not necessarily available, and can be considered an implementation detail at best. Also, note that ispunct() and isprint() are available in the curses.ascii module. ------------------------------------------------------- Date: 2000-Sep-14 09:40 By: fdrake Comment: Response from Richard Mortier: Ah -- this was originally generated because I wanted to use it in Python 1.5.2 -- didn't realise later versions had curses.ascii Not defining them in string.py was because I wanted the behaviour of isprint() (in particular). ------------------------------------------------------- Date: 2000-Sep-14 09:43 By: fdrake Comment: My response to Richard: But why not just take the resulting value from your patch and add a couple of lines to Lib/string.py: printable = "..." punctuation = "..." If you can create an updated patch with this, and add a comment to the SourceForge interface explaining why these would be useful, we can consider it. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101507&group_id=5470 From noreply@sourceforge.net Thu Sep 14 18:15:14 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 10:15:14 -0700 Subject: [Patches] [Patch #101509] Fix for 114424: PyTuple_Resize buggy with cyclic gc Message-ID: <200009141715.KAA28947@delerium.i.sourceforge.net> Patch #101509 has been updated. Project: Category: core (C code) Status: Open Summary: Fix for 114424: PyTuple_Resize buggy with cyclic gc ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101509&group_id=5470 From noreply@sourceforge.net Thu Sep 14 18:30:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 10:30:53 -0700 Subject: [Patches] [Patch #101510] Fix for 114424: PyTuple_Resize buggy with cyclic gc Message-ID: <200009141730.KAA11013@bush.i.sourceforge.net> Patch #101510 has been updated. Project: Category: core (C code) Status: Open Summary: Fix for 114424: PyTuple_Resize buggy with cyclic gc ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101510&group_id=5470 From noreply@sourceforge.net Thu Sep 14 18:51:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 10:51:35 -0700 Subject: [Patches] [Patch #101509] Fix for 114424: PyTuple_Resize buggy with cyclic gc Message-ID: <200009141751.KAA11859@bush.i.sourceforge.net> Patch #101509 has been updated. Project: Category: core (C code) Status: Open Summary: Fix for 114424: PyTuple_Resize buggy with cyclic gc ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101509&group_id=5470 From noreply@sourceforge.net Thu Sep 14 18:52:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 10:52:04 -0700 Subject: [Patches] [Patch #101486] Unexpected Evaluation of Expressions from Pickle Patch Message-ID: <200009141752.KAA11871@bush.i.sourceforge.net> Patch #101486 has been updated. Project: Category: Modules Status: Open Summary: Unexpected Evaluation of Expressions from Pickle Patch ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101486&group_id=5470 From noreply@sourceforge.net Thu Sep 14 19:02:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 11:02:38 -0700 Subject: [Patches] [Patch #101511] Fix typos Message-ID: <200009141802.LAA30758@delerium.i.sourceforge.net> Patch #101511 has been updated. Project: Category: XML Status: Open Summary: Fix typos ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101511&group_id=5470 From noreply@sourceforge.net Thu Sep 14 19:05:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 11:05:03 -0700 Subject: [Patches] [Patch #101511] Fix typos Message-ID: <200009141805.LAA30892@delerium.i.sourceforge.net> Patch #101511 has been updated. Project: Category: XML Status: Open Summary: Fix typos ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101511&group_id=5470 From noreply@sourceforge.net Thu Sep 14 19:05:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 11:05:54 -0700 Subject: [Patches] [Patch #101512] Support parsing of already opened file objects Message-ID: <200009141805.LAA30901@delerium.i.sourceforge.net> Patch #101512 has been updated. Project: Category: XML Status: Open Summary: Support parsing of already opened file objects ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101512&group_id=5470 From noreply@sourceforge.net Thu Sep 14 19:06:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 11:06:08 -0700 Subject: [Patches] [Patch #101512] Support parsing of already opened file objects Message-ID: <200009141806.LAA30905@delerium.i.sourceforge.net> Patch #101512 has been updated. Project: Category: XML Status: Open Summary: Support parsing of already opened file objects ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101512&group_id=5470 From noreply@sourceforge.net Thu Sep 14 19:10:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 11:10:32 -0700 Subject: [Patches] [Patch #101514] Fix inheritance hierarchy, remove references to self._source Message-ID: <200009141810.LAA31067@delerium.i.sourceforge.net> Patch #101514 has been updated. Project: Category: XML Status: Open Summary: Fix inheritance hierarchy, remove references to self._source ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101514&group_id=5470 From noreply@sourceforge.net Thu Sep 14 18:33:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 10:33:00 -0700 Subject: [Patches] [Patch #101510] Fix for 114424: PyTuple_Resize buggy with cyclic gc Message-ID: <200009141733.KAA11048@bush.i.sourceforge.net> Patch #101510 has been updated. Project: Category: core (C code) Status: Deleted Summary: Fix for 114424: PyTuple_Resize buggy with cyclic gc Follow-Ups: Date: 2000-Sep-14 10:32 By: loewis Comment: Duplicate of 101509 when Reload in Netscape reposted the form data. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101510&group_id=5470 From noreply@sourceforge.net Thu Sep 14 19:10:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 11:10:43 -0700 Subject: [Patches] [Patch #101514] Fix inheritance hierarchy, remove references to self._source Message-ID: <200009141810.LAA31079@delerium.i.sourceforge.net> Patch #101514 has been updated. Project: Category: XML Status: Open Summary: Fix inheritance hierarchy, remove references to self._source ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101514&group_id=5470 From noreply@sourceforge.net Thu Sep 14 19:11:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 11:11:09 -0700 Subject: [Patches] [Patch #100803] puremodule: ANSI-fication (UNTESTED!) Message-ID: <200009141811.LAA12743@bush.i.sourceforge.net> Patch #100803 has been updated. Project: Category: None Status: Open Summary: puremodule: ANSI-fication (UNTESTED!) Follow-Ups: Date: 2000-Jul-10 10:16 By: nowonder Comment: cannot test this, maybe Barry can ------------------------------------------------------- Date: 2000-Jul-31 01:46 By: nowonder Comment: should I just check it in? Did you get around to review it? ------------------------------------------------------- Date: 2000-Jul-31 09:30 By: bwarsaw Comment: There's one typo in nowonder's patch. Here's a fixed version of the patch (unified). This compiles but doesn't link. I can't tell if this is caused by a problem with the purify stub libraries. Meta note: because this is a commercial product which it seems no one has access to anymore, should we continue to support it in the standard distribution? ------------------------------------------------------- Date: 2000-Jul-31 10:30 By: gvanrossum Comment: Since no-one can test this, let's be conservative and not check it in. There's no absolute requirement to move *everything* to ANSI. Since we know the old version worked, we should leave it alone. I vote to keep this in the distribution -- maybe someone else can use it. If someone else can confirm that it in fact works (or make it work) I'd be happy to accept the patch at that point. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100803&group_id=5470 From noreply@sourceforge.net Thu Sep 14 19:15:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 11:15:22 -0700 Subject: [Patches] [Patch #101512] Support parsing of already opened file objects Message-ID: <200009141815.LAA12944@bush.i.sourceforge.net> Patch #101512 has been updated. Project: Category: XML Status: Open Summary: Support parsing of already opened file objects Follow-Ups: Date: 2000-Sep-14 11:15 By: jhylton Comment: I don't particularly care for this interface change. It appears that the parser will close the file if passed as an argument. Since the parser did not open the file, it should not close it. It seems to me that this feature should be a separate method. Also, there seem to be a lot of style problems with this code. There is inconsistent use of whitespace around ()s and =s. It should be consistent above all! And it should use the approved Python style. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101512&group_id=5470 From noreply@sourceforge.net Thu Sep 14 19:27:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 11:27:19 -0700 Subject: [Patches] [Patch #101233] PyModule_AddObject() and friends Message-ID: <200009141827.LAA13357@bush.i.sourceforge.net> Patch #101233 has been updated. Project: Category: core (C code) Status: Open Summary: PyModule_AddObject() and friends Follow-Ups: Date: 2000-Aug-19 10:17 By: marangoz Comment: Looks good. BDFL need to Pronounce on API issues. What amount of changes would this imply in the distrib? Have patch? (the names could be tuned later directly in the patch ) ------------------------------------------------------- Date: 2000-Aug-19 21:31 By: tim_one Comment: Assigned to Guido because, as Vlad says, he needs to Prounounce on the idea. Guido, the point here is to provide a single implementation to replace all the repeated and inconsistent functions and macros that modules are defining today for use in their init functions. Was discussed on Python-Dev and was well-received there. Andrew, I dislike the name PyModule_AddConstantLong, because that Python ints *happen* to be C longs should be an implementation detail. Since the function is actually adding a Python int, I'm afraid I like PyModule_AddConstantInt better. Oh, yuck. Ah! PyModule_AddConstantPyInt. ------------------------------------------------------- Date: 2000-Aug-21 17:46 By: gvanrossum Comment: I like the idea fine, but don't think it's important enough to rush it into 2.0. Anyway it needs docs for api.tex. AddConstantPyInt is a bad name becase "PyInt" suggests that the argument is a Python int object, not a C int. Suggestion: PyModule_AddIntConstant and PyModule_AddStringConstant. I'm a bit worried by the implied DECREF in PyModule_AddObject -- this should better go into the other two, or the name should be changed, maybe to _AddNewObject. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101233&group_id=5470 From noreply@sourceforge.net Thu Sep 14 19:27:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 11:27:39 -0700 Subject: [Patches] [Patch #101387] Documenting __contains__ special method Message-ID: <200009141827.LAA13375@bush.i.sourceforge.net> Patch #101387 has been updated. Project: Category: documentation Status: Open Summary: Documenting __contains__ special method Follow-Ups: Date: 2000-Sep-01 07:38 By: jhylton Comment: Moshe please review but do not accept or check in until we give you the go ahead. These patches arrived too late for 2.0b1. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101387&group_id=5470 From noreply@sourceforge.net Thu Sep 14 19:28:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 11:28:40 -0700 Subject: [Patches] [Patch #101509] Fix for 114424: PyTuple_Resize buggy with cyclic gc Message-ID: <200009141828.LAA13485@bush.i.sourceforge.net> Patch #101509 has been updated. Project: Category: core (C code) Status: Open Summary: Fix for 114424: PyTuple_Resize buggy with cyclic gc Follow-Ups: Date: 2000-Sep-14 11:28 By: nascheme Comment: This looks like a real bug. If realloc returns a new pointer then using g is wrong. I'm not sure about this patch though. I think the realloc line should be changed to: g = (PyTupleObject *) PyObject_REALLOC((char *)g, ...) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101509&group_id=5470 From noreply@sourceforge.net Thu Sep 14 21:05:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 13:05:47 -0700 Subject: [Patches] [Patch #101425] Fix for 110598: support \r in py_compile Message-ID: <200009142005.NAA17380@bush.i.sourceforge.net> Patch #101425 has been updated. Project: Category: library Status: Accepted Summary: Fix for 110598: support \r in py_compile ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101425&group_id=5470 From noreply@sourceforge.net Thu Sep 14 21:00:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 13:00:12 -0700 Subject: [Patches] [Patch #101423] Fix for 110686: cStringIO.readlines Message-ID: <200009142000.NAA17153@bush.i.sourceforge.net> Patch #101423 has been updated. Project: Category: library Status: Open Summary: Fix for 110686: cStringIO.readlines ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101423&group_id=5470 From noreply@sourceforge.net Thu Sep 14 20:42:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 12:42:17 -0700 Subject: [Patches] [Patch #101514] Remove references to self._source Message-ID: <200009141942.MAA01863@delerium.i.sourceforge.net> Patch #101514 has been updated. Project: Category: XML Status: Open Summary: Remove references to self._source Follow-Ups: Date: 2000-Sep-14 12:37 By: prescod Comment: (this update to the patch makes fewer changes to the original code than the original patch based on the philosophy that it will be easier for Lars to apply his fixes if the code changes as little as possible) Read the comment about InputSource in the patch. All references to self._source are removed. Remove special case handling of streams versus strings (done in xmlreader now). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101514&group_id=5470 From noreply@sourceforge.net Thu Sep 14 19:32:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 11:32:12 -0700 Subject: [Patches] [Patch #101389] Minor fix in documentation of code module Message-ID: <200009141832.LAA13577@bush.i.sourceforge.net> Patch #101389 has been updated. Project: Category: documentation Status: Open Summary: Minor fix in documentation of code module ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101389&group_id=5470 From noreply@sourceforge.net Thu Sep 14 19:32:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 11:32:43 -0700 Subject: [Patches] [Patch #101391] Implemented UserList.__contains__ Message-ID: <200009141832.LAA13583@bush.i.sourceforge.net> Patch #101391 has been updated. Project: Category: Modules Status: Open Summary: Implemented UserList.__contains__ Follow-Ups: Date: 2000-Sep-01 07:42 By: jhylton Comment: you know the drill ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101391&group_id=5470 From noreply@sourceforge.net Thu Sep 14 21:10:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 13:10:19 -0700 Subject: [Patches] [Patch #101433] Fix for 110845: Check struct short and byte ranges Message-ID: <200009142010.NAA17589@bush.i.sourceforge.net> Patch #101433 has been updated. Project: Category: library Status: Accepted Summary: Fix for 110845: Check struct short and byte ranges ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101433&group_id=5470 From noreply@sourceforge.net Thu Sep 14 19:33:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 11:33:35 -0700 Subject: [Patches] [Patch #101388] Backward compatibility hook Message-ID: <200009141833.LAA13598@bush.i.sourceforge.net> Patch #101388 has been updated. Project: Category: documentation Status: Open Summary: Backward compatibility hook Follow-Ups: Date: 2000-Sep-01 07:41 By: jhylton Comment: same deal: postponed for now, but may be considered post 2.0b1 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101388&group_id=5470 From noreply@sourceforge.net Thu Sep 14 19:34:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 11:34:08 -0700 Subject: [Patches] [Patch #101390] Add special names to operator module as expected by user Message-ID: <200009141834.LAA13711@bush.i.sourceforge.net> Patch #101390 has been updated. Project: Category: library Status: Open Summary: Add special names to operator module as expected by user Follow-Ups: Date: 2000-Sep-01 07:42 By: jhylton Comment: third one: postponed for now ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101390&group_id=5470 From noreply@sourceforge.net Thu Sep 14 20:37:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 12:37:18 -0700 Subject: [Patches] [Patch #101514] Remove references to self._source Message-ID: <200009141937.MAA01673@delerium.i.sourceforge.net> Patch #101514 has been updated. Project: Category: XML Status: Open Summary: Remove references to self._source Follow-Ups: Date: 2000-Sep-14 12:37 By: prescod Comment: (this update to the patch makes fewer changes to the original code than the original patch based on the philosophy that it will be easier for Lars to apply his fixes if the code changes as little as possible) Read the comment about InputSource in the patch. All references to self._source are removed. Remove special case handling of streams versus strings (done in xmlreader now). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101514&group_id=5470 From noreply@sourceforge.net Thu Sep 14 19:36:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 11:36:32 -0700 Subject: [Patches] [Patch #100927] Fix for broken gethostbyname("0") Message-ID: <200009141836.LAA13751@bush.i.sourceforge.net> Patch #100927 has been updated. Project: Category: Modules Status: Open Summary: Fix for broken gethostbyname("0") Follow-Ups: Date: 2000-Jul-19 01:46 By: effbot Comment: why should this work? why is "gethostbyname" broken if it doesn't support "0" and "-1"? if it's important to support these values, shouldn't they be passed to the function as integers, not as strings? etc. (sorry, I'm usually able to make some kind of sense out of patches, but this one was a bit too cryptic ;-) ------------------------------------------------------- Date: 2000-Jul-20 23:13 By: ppessi Comment: It is not important to support "-1". "0" is INADDR_ANY in dot notation - same as "0.0.0.0" or "0.0.0" or "0.0". gethostbyname() should understand dot notation as well as domain names. For some reason, Windows gethostbyname() does not support "0" (obviously I'm a lazy typer, since I have not noticed that it does not support 0.0 nor 0.0.0 nor 0.0.0.0) unlike Unix platforms. I'll supply another patch ACN. ------------------------------------------------------- Date: 2000-Aug-13 19:49 By: nowonder Comment: As linux supports "0" (as well as "0.0" and friends), this would be nice to reduce platform dependency. But "00" is just as valid (not sure what Windows does with it), so to check this I think a bit more work has to be done. ------------------------------------------------------- Date: 2000-Aug-15 10:50 By: tim_one Comment: Changed status from Open to Postponed. There's been no action on this patch despite comments. If you want it to go into 2.0, address the concerns on Python-Dev Real Quick, and if so I'll Open it again. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100927&group_id=5470 From noreply@sourceforge.net Thu Sep 14 19:38:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 11:38:57 -0700 Subject: [Patches] [Patch #101482] fix for Bug #114245 Message-ID: <200009141838.LAA13894@bush.i.sourceforge.net> Patch #101482 has been updated. Project: Category: core (C code) Status: Open Summary: fix for Bug #114245 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101482&group_id=5470 From noreply@sourceforge.net Thu Sep 14 21:29:27 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 13:29:27 -0700 Subject: [Patches] [Patch #101437] Fix for 110675: GNU pth support Message-ID: <200009142029.NAA03713@delerium.i.sourceforge.net> Patch #101437 has been updated. Project: Category: core (C code) Status: Open Summary: Fix for 110675: GNU pth support Follow-Ups: Date: 2000-Sep-06 17:01 By: adustman Comment: Makes better use of GNU autoconf. configure --with-pth[=DIR] # --with-threads implied Passes test_fork1 and test_thread. Tested with pth-1.3.7. XXX With pth, select() (and others) do not wake up in response to signals. Example: >>> import time >>> time.sleep(10) [hit ctrl-C, no response for 10 seconds] Traceback (most recent call last): File "", line 1, in ? KeyboardInterrupt >>> I have a patch to pth that fixes this that I will try to get incorporated. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101437&group_id=5470 From noreply@sourceforge.net Thu Sep 14 21:43:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 13:43:13 -0700 Subject: [Patches] [Patch #101389] Minor fix in documentation of code module Message-ID: <200009142043.NAA18775@bush.i.sourceforge.net> Patch #101389 has been updated. Project: Category: documentation Status: Closed Summary: Minor fix in documentation of code module Follow-Ups: Date: 2000-Sep-14 13:43 By: fdrake Comment: Checked in as Doc/lib/libcode.tex revision 1.12. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101389&group_id=5470 From noreply@sourceforge.net Thu Sep 14 19:41:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 11:41:04 -0700 Subject: [Patches] [Patch #101481] fix for Bug #113894 in ntpath.py and posixmodule.c Message-ID: <200009141841.LAA13936@bush.i.sourceforge.net> Patch #101481 has been updated. Project: Category: library Status: Open Summary: fix for Bug #113894 in ntpath.py and posixmodule.c ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101481&group_id=5470 From noreply@sourceforge.net Thu Sep 14 22:08:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 14:08:47 -0700 Subject: [Patches] [Patch #101512] Support parsing of already opened file objects Message-ID: <200009142108.OAA19721@bush.i.sourceforge.net> Patch #101512 has been updated. Project: Category: XML Status: Open Summary: Support parsing of already opened file objects Follow-Ups: Date: 2000-Sep-14 11:15 By: jhylton Comment: I don't particularly care for this interface change. It appears that the parser will close the file if passed as an argument. Since the parser did not open the file, it should not close it. It seems to me that this feature should be a separate method. Also, there seem to be a lot of style problems with this code. There is inconsistent use of whitespace around ()s and =s. It should be consistent above all! And it should use the approved Python style. ------------------------------------------------------- Date: 2000-Sep-14 12:21 By: prescod Comment: This isn't an interface change, it just makes the interface work the way it says it does. If fixes a FIXME. A separate method is a good idea but it would have to be agreed upon by the xml-sig (or at least implemented by Lars, the main SAX maintainer). I see that as part of the larger refactoring that Lars is doing. I'm not clear what line of code closes the file. It looks to me like it just goes out of scope still open. ------------------------------------------------------- Date: 2000-Sep-14 14:08 By: fdrake Comment: I'm hesitant to approve this myself; I don't like the overloading. (Though I agree that this simply brings the implementation into line with the documentation, such as it is.) The Java equivelent uses an overloaded parse() method, but Java provides direct support for this in the language definition. I think the Python SAX2 definition should provide separate methods. Let's wait for Lars to weigh in on the API issues. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101512&group_id=5470 From noreply@sourceforge.net Thu Sep 14 21:46:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 13:46:05 -0700 Subject: [Patches] [Patch #101511] Fix typos Message-ID: <200009142046.NAA18924@bush.i.sourceforge.net> Patch #101511 has been updated. Project: Category: XML Status: Accepted Summary: Fix typos Follow-Ups: Date: 2000-Sep-14 13:46 By: fdrake Comment: Please check this in -- thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101511&group_id=5470 From noreply@sourceforge.net Thu Sep 14 21:49:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 13:49:02 -0700 Subject: [Patches] [Patch #101394] lookdict optimizations Message-ID: <200009142049.NAA04488@delerium.i.sourceforge.net> Patch #101394 has been updated. Project: Category: core (C code) Status: Open Summary: lookdict optimizations Follow-Ups: Date: 2000-Sep-03 21:09 By: marangoz Comment: Let's add a comment, although this has been raised on python-dev. This patch proposes a couple of ideas for optimizing & speeding dict lookups -- not all of them need to be applied though. - clear the eventual errors from Object_Compare only on need (this logic needs to be double-checked once again to see whether it really works) - defer variable initializations after the most common return cases - specialize string_compare() for lookdict_string. The test comparing the first char, before calling memcmp(), can be added too. - inline the first item probe in PyDict_GetItem. This saves a func call for the most common case (common to lookdict & lookdict_string). ------------------------------------------------------- Date: 2000-Sep-04 06:45 By: gvanrossum Comment: Quick comments: we should *always* call PyErr_Occurred() after PyObject_Compare() (and PyErr_Clear() if PyErr_Occurred() returned true). PyErr_Compare() really doesn't expect a pending exception coming in and so *not* clearing the error might break the *next* PyErr_Compare() call. (This doesn't happen typically but PyObject_Compare() can execute arbitrary code, some of which might call PyErr_Occurred() without calling PyErr_Clear() first.) ------------------------------------------------------- Date: 2000-Sep-05 06:05 By: none Comment: Correct! But then, aren't the current "else" if(cmp == 0) clauses risky after PyObject_Compare()? An exception may be set in external code while making Object_Compare() to return 0! Perhaps not in Python source, but in buggy extensions. lookdict() will then overlook this "hit". Patch updated, without "else" clauses and with the 1st char check in string_compare_equal(). ------------------------------------------------------- Date: 2000-Sep-05 06:08 By: marangoz Comment: Argh! These Web interfaces strike again - forgot to login. ------------------------------------------------------- Date: 2000-Sep-14 09:26 By: fdrake Comment: Revised patch: Instead of defining a function to do the fast string comparison, use a macro, but let it use the documented string object API (PyString_GET_SIZE(), PyString_AS_STRING()) instead of breaking the encapsulation in the code. This avoids all function calls to do the string compare, except memcmp() (which good compilers can inline anyway). Vladimir, take a look at this; if you're happy, I'm happy, and you can check it in. Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101394&group_id=5470 From noreply@sourceforge.net Thu Sep 14 21:49:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 13:49:22 -0700 Subject: [Patches] [Patch #101514] Remove references to self._source Message-ID: <200009142049.NAA19070@bush.i.sourceforge.net> Patch #101514 has been updated. Project: Category: XML Status: Accepted Summary: Remove references to self._source Follow-Ups: Date: 2000-Sep-14 12:37 By: prescod Comment: (this update to the patch makes fewer changes to the original code than the original patch based on the philosophy that it will be easier for Lars to apply his fixes if the code changes as little as possible) Read the comment about InputSource in the patch. All references to self._source are removed. Remove special case handling of streams versus strings (done in xmlreader now). ------------------------------------------------------- Date: 2000-Sep-14 13:49 By: fdrake Comment: Please don't comment out the lines; just remove them. CVS will keep the history of what happened just fine. Please make this mechanical change and check it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101514&group_id=5470 From noreply@sourceforge.net Thu Sep 14 21:49:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 13:49:33 -0700 Subject: [Patches] [Patch #101412] add gc.DEBUG_SAVEALL option, gc_str fix Message-ID: <200009142049.NAA04506@delerium.i.sourceforge.net> Patch #101412 has been updated. Project: Category: core (C code) Status: Open Summary: add gc.DEBUG_SAVEALL option, gc_str fix Follow-Ups: Date: 2000-Sep-03 20:13 By: marangoz Comment: Looks good. I approve the str fix. One nit: "else" clauses usually go to a new line in the Python source. Make it "else if" on a new line. Questions: - DEBUG_LEAK now includes SAVEALL. The regression test suite sets DEBUG_LEAK by default. It used to report a bunch of objects during test_gc. Now it will collect the detected cycles in the suite. Should regrtest.py report them somehow? - After the regression test, gc.garbage contains an A instance and an empty list. I think they're created by test_gc. Can't they be cleared? We can assign gc.garbage = [], but this doesn't clear anything. - test_gc/test_saveall has gc.set_debug(0), followed immediately by gc.set_debug(gc.DEBUG_SAVEALL). Is this on purpose or is it a typo? BTW, I don't quite understand why this function does what it does... Could you elaborate on it? ------------------------------------------------------- Date: 2000-Sep-04 07:05 By: nascheme Comment: - regrtest will print the repr of cyclic garbage found if -l option is specified and -q is not - put else on newline in accordance with Python style - constrain debugging options during test_gc (don't enabled DEBUG_LEAK) - fix test_gc to remove garbage from gc.garbage ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101412&group_id=5470 From noreply@sourceforge.net Thu Sep 14 21:51:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 13:51:21 -0700 Subject: [Patches] [Patch #101394] lookdict optimizations Message-ID: <200009142051.NAA19107@bush.i.sourceforge.net> Patch #101394 has been updated. Project: Category: core (C code) Status: Open Summary: lookdict optimizations Follow-Ups: Date: 2000-Sep-03 21:09 By: marangoz Comment: Let's add a comment, although this has been raised on python-dev. This patch proposes a couple of ideas for optimizing & speeding dict lookups -- not all of them need to be applied though. - clear the eventual errors from Object_Compare only on need (this logic needs to be double-checked once again to see whether it really works) - defer variable initializations after the most common return cases - specialize string_compare() for lookdict_string. The test comparing the first char, before calling memcmp(), can be added too. - inline the first item probe in PyDict_GetItem. This saves a func call for the most common case (common to lookdict & lookdict_string). ------------------------------------------------------- Date: 2000-Sep-04 06:45 By: gvanrossum Comment: Quick comments: we should *always* call PyErr_Occurred() after PyObject_Compare() (and PyErr_Clear() if PyErr_Occurred() returned true). PyErr_Compare() really doesn't expect a pending exception coming in and so *not* clearing the error might break the *next* PyErr_Compare() call. (This doesn't happen typically but PyObject_Compare() can execute arbitrary code, some of which might call PyErr_Occurred() without calling PyErr_Clear() first.) ------------------------------------------------------- Date: 2000-Sep-05 06:05 By: none Comment: Correct! But then, aren't the current "else" if(cmp == 0) clauses risky after PyObject_Compare()? An exception may be set in external code while making Object_Compare() to return 0! Perhaps not in Python source, but in buggy extensions. lookdict() will then overlook this "hit". Patch updated, without "else" clauses and with the 1st char check in string_compare_equal(). ------------------------------------------------------- Date: 2000-Sep-05 06:08 By: marangoz Comment: Argh! These Web interfaces strike again - forgot to login. ------------------------------------------------------- Date: 2000-Sep-14 09:26 By: fdrake Comment: Revised patch: Instead of defining a function to do the fast string comparison, use a macro, but let it use the documented string object API (PyString_GET_SIZE(), PyString_AS_STRING()) instead of breaking the encapsulation in the code. This avoids all function calls to do the string compare, except memcmp() (which good compilers can inline anyway). Vladimir, take a look at this; if you're happy, I'm happy, and you can check it in. Thanks! ------------------------------------------------------- Date: 2000-Sep-14 13:51 By: fdrake Comment: Guido, please review (since Vladimir's away). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101394&group_id=5470 From noreply@sourceforge.net Thu Sep 14 19:53:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 11:53:59 -0700 Subject: [Patches] [Patch #101509] Fix for 114424: PyTuple_Resize buggy with cyclic gc Message-ID: <200009141853.LAA14487@bush.i.sourceforge.net> Patch #101509 has been updated. Project: Category: core (C code) Status: Open Summary: Fix for 114424: PyTuple_Resize buggy with cyclic gc Follow-Ups: Date: 2000-Sep-14 11:28 By: nascheme Comment: This looks like a real bug. If realloc returns a new pointer then using g is wrong. I'm not sure about this patch though. I think the realloc line should be changed to: g = (PyTupleObject *) PyObject_REALLOC((char *)g, ...) ------------------------------------------------------- Date: 2000-Sep-14 11:53 By: loewis Comment: You are right. I've uploaded a revised patch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101509&group_id=5470 From noreply@sourceforge.net Thu Sep 14 22:53:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 14:53:37 -0700 Subject: [Patches] [Patch #101454] Add Unicode support to "exec" and "eval()" Message-ID: <200009142153.OAA06907@delerium.i.sourceforge.net> Patch #101454 has been updated. Project: Category: core (C code) Status: Accepted Summary: Add Unicode support to "exec" and "eval()" Follow-Ups: Date: 2000-Sep-08 13:53 By: lemburg Comment: This patch adds support for Unicode objects to exec and eval(). Unicode objects are converted to default encoded strings prior to processing them with the usual logic. ------------------------------------------------------- Date: 2000-Sep-14 14:53 By: gvanrossum Comment: Go for it. Semi-related question: is there no more elegant way to spell "take this object which I know to be an 8-bit or Unicode string and give me a pointer to a C string containing its 8-bit equivalent, if possible" than PyArg_Parse(obj, "s:tata", &s)? Seems it could use a new C API. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101454&group_id=5470 From noreply@sourceforge.net Thu Sep 14 23:08:27 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 15:08:27 -0700 Subject: [Patches] [Patch #101458] Adding Unicode support to get|set|hasattr() Message-ID: <200009142208.PAA07528@delerium.i.sourceforge.net> Patch #101458 has been updated. Project: Category: core (C code) Status: Open Summary: Adding Unicode support to get|set|hasattr() Follow-Ups: Date: 2000-Sep-08 14:48 By: lemburg Comment: This patch add Unicode support to the PyObject_SetAttr() and PyObject_GetAttr() APIs which are used by the mentioned builtin functions to set or query attributes. While implementing the patch I found that all current tp_getattro and tp_setattro implementations (classes, instances, methods) expect to find string objects as argument and don't even check for this. The patch realizes this behaviour by only accepting string or Unicode objects as name parameter to the two C APIs. ------------------------------------------------------- Date: 2000-Sep-14 15:08 By: gvanrossum Comment: Almost OK. You missed delattr()! Since that's a trivial fix, just check in the fixed patch and close the patch in SF. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101458&group_id=5470 From noreply@sourceforge.net Thu Sep 14 22:46:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 14:46:59 -0700 Subject: [Patches] [Patch #101454] Add Unicode support to "exec" and "eval()" Message-ID: <200009142146.OAA06679@delerium.i.sourceforge.net> Patch #101454 has been updated. Project: Category: core (C code) Status: Open Summary: Add Unicode support to "exec" and "eval()" Follow-Ups: Date: 2000-Sep-08 13:53 By: lemburg Comment: This patch adds support for Unicode objects to exec and eval(). Unicode objects are converted to default encoded strings prior to processing them with the usual logic. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101454&group_id=5470 From noreply@sourceforge.net Thu Sep 14 22:47:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 14:47:28 -0700 Subject: [Patches] [Patch #101458] Adding Unicode support to get|set|hasattr() Message-ID: <200009142147.OAA06700@delerium.i.sourceforge.net> Patch #101458 has been updated. Project: Category: core (C code) Status: Open Summary: Adding Unicode support to get|set|hasattr() Follow-Ups: Date: 2000-Sep-08 14:48 By: lemburg Comment: This patch add Unicode support to the PyObject_SetAttr() and PyObject_GetAttr() APIs which are used by the mentioned builtin functions to set or query attributes. While implementing the patch I found that all current tp_getattro and tp_setattro implementations (classes, instances, methods) expect to find string objects as argument and don't even check for this. The patch realizes this behaviour by only accepting string or Unicode objects as name parameter to the two C APIs. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101458&group_id=5470 From noreply@sourceforge.net Thu Sep 14 23:39:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 15:39:02 -0700 Subject: [Patches] [Patch #100947] increase control and default size of pdb traceback display Message-ID: <200009142239.PAA08816@delerium.i.sourceforge.net> Patch #100947 has been updated. Project: Category: library Status: Rejected Summary: increase control and default size of pdb traceback display Follow-Ups: Date: 2000-Aug-13 20:15 By: nowonder Comment: There is a detailed description in the patch. ------------------------------------------------------- Date: 2000-Aug-15 10:55 By: tim_one Comment: Reassigned to Guido in Jeremy's absence, cuz I never use pdb but know Guido has at least once . Please review or pass on to someone else. ------------------------------------------------------- Date: 2000-Aug-17 12:36 By: gvanrossum Comment: I like the idea fine, but the command name "scaletb" sucks. Once a better name is coined Ken should get checkin permissions if he doesn't already have them, so he can check it in. (Isn't it ironic that Ken, who enjoys naming debates so much, came up with a sucky name? :-) Possibly a better name could include "control" (or an abbreviation) instead of "scale"? ------------------------------------------------------- Date: 2000-Aug-21 16:59 By: tim_one Comment: Ken, are you going to repsond to Guido's comments? And do you want developer privileges? ------------------------------------------------------- Date: 2000-Aug-27 09:57 By: klm Comment: Sorry about not responding more promptly. Actually, i got the email for guido's patch comment, and wasn't sure who to contact about getting checkin privileges, so was waiting for a moment to look around a bit to track that down and think things through. It so happens (1) i didn't get the moment until this morning (!), and (2) i must have missed tim's subsequent comment in my email box, because this is the first i saw of it. I do seem to have cvs ssh access, now, and have an alternate name to suggest. I'd be happy to arrive at some agreement on a name and then check in the changes. My current suggestion is 'limit_tb', with no abbreviation. I think this name is a lot more self-evident than scaletb, and a lot more specific than something like 'control_tb'. I can see objections to this, and am open to other suggestions. (If you insist on 'control_tb' or somesuch, fine.) Though this is Just A Name, there are some complications arriving at a name that fits well with the pdb commands. First, none of the other pdb command names are very long, so while "limit_traceback" would be most clear, it would be out of place. And cumbersome. Inclusion of an underscore in a pdb command name is, itself, unprecedented, but that helps avoid confusion with the "tb" of 'tbreak' (where "tb" => "temporary break"). Perhaps the "tb" collision is enough reason to spell out "traceback" - but incongruous and cumbersome, see above. Perhaps the most comprehensive solution would be to have a pdb "set" command, to set operational options, and then have a "set traceback_limit". That seems much too elaborate for a single option. It also seems like overkill even for several options, if there's no persistence to the pdb configuration - too much for settings that only last for a python session. While there may or may not be good reasons to have a persistent mechanism, i think the limit_tb command would be quite useful without it - people can enlarge the tb size once they see it's necessary, and reevoke it. So i'm for 'limit_tb', but open to other suggestions, willing to accept an edict if that means i can just check this in (or try another approach). (I think i'm set to do the checkin - i assume my addition to the python project developers roster means i have the privileges, and i've applied the patch to an ssh checkout, ready and sort of eager to try the checkin...) Ken ------------------------------------------------------- Date: 2000-Aug-31 14:36 By: jhylton Comment: Ken has disappeared ------------------------------------------------------- Date: 2000-Sep-07 17:14 By: klm Comment: Here's a new patch using "limit_tb" instead of "scaletb" as the name. I also realize that the changes to repr - presentation limits added as parameters on __init__, plus a "multiplication factor" to make it easy to change from standard limits with one easy value - ought to be documented in the repr standard library docs. I'll pursue that, if necessary, but wanted to see if this new name, and the rest of the patch, passes muster. As jeremy suggested, i will setting the "assigned to" to guido, so he judge it. (Except i don't see how to reassign - perhaps that comes next, after submitting this?? Murgh.) ------------------------------------------------------- Date: 2000-Sep-14 15:39 By: gvanrossum Comment: I apologize profusely. I thought this code would limit the number of stack trace entries printed by the 'where' command. It does nothing of the kind! I did not read the patch very carefully the first time! Instead, it adds more flexibility in the truncation applied to long values by the repr module's Repr() class, and adds a command to the pdb module that allows coarse "scaling" of the truncation parameters used in *one* specific instance: the value of an exception printed at the end of the traceback. I'm okay with the change to the repr module, except that it's got a stupid name (a standard module with the same name as a standard function? Give me a break!), and therefore alone deserves to be replaced by something a bit more well-thought-out. As far as the use of the repr module in the pdb module goes, I think that the risk it is trying to avoid by using repr.repr() is absolutely minimal (after all it's printing an exception -- something typically designed to have a brief printable representation) and the proper solution to Ken's original problem (which I'm guessing is that not enough information was printed in a case he cared about) should be to just print the exception rather than using the repr module. Again, I apologize for the time wasted by all, but we have a feature freeze to obey. I *might* approve the change I propose to pdb.py as a bugfix -- after all it is a bug when it truncates too much information from the exception (though you can easily print it from pdb with "import sys; print sys.exc_value"). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100947&group_id=5470 From noreply@sourceforge.net Thu Sep 14 19:23:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 11:23:55 -0700 Subject: [Patches] [Patch #100899] a smaller unicode name database Message-ID: <200009141823.LAA13267@bush.i.sourceforge.net> Patch #100899 has been updated. Project: Category: None Status: Open Summary: a smaller unicode name database Follow-Ups: Date: 2000-Jul-15 15:43 By: effbot Comment: duh. it's too large for sourceforge. if you want to play with it, get it from: http://w1.132.telia.com/~u13208596/uninames-patch.txt ------------------------------------------------------- Date: 2000-Aug-03 11:59 By: lemburg Comment: How is the work on this patch coming along ? Will it be ready for 2.0 ? ------------------------------------------------------- Date: 2000-Aug-15 10:42 By: tim_one Comment: /F or MAL, what's going on with this? MAL, did you look at the patch? /F, do you feel it's done? ------------------------------------------------------- Date: 2000-Aug-23 11:39 By: tim_one Comment: Assigned back to /F because he agrees the ball bounced back into his court: [/F, in Python-Dev mail] mal has reviewed the patch, and is waiting for an update from me. ------------------------------------------------------- Date: 2000-Aug-24 04:37 By: lemburg Comment: I'd rather see this patch postponed. Reason: We're not in a hury here -- better get this done right than to quickly throw together a set of patches without some more extensive testing. Comment for future reference: --------------------- Note that I would also like to unify the different Unicode databases (ctype DBs, Unicode DB and Unicode name DB) into one single unicodedb access module which will be written in Python. The sibling C modules can then be loaded dynamically and in a lazy fashion. This will result in an implementation which should be much easier to maintain than the current (2.0) setup. ------------------------------------------------------- Date: 2000-Aug-28 11:55 By: effbot Comment: postponed, for now. I'm still working on the full unidb package, and will reopen this patch again when I've fixed the other things that needs to be fixed before 2.0b1. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100899&group_id=5470 From noreply@sourceforge.net Thu Sep 14 19:24:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 11:24:56 -0700 Subject: [Patches] [Patch #100947] increase control and default size of pdb traceback display Message-ID: <200009141824.LAA13303@bush.i.sourceforge.net> Patch #100947 has been updated. Project: Category: library Status: Open Summary: increase control and default size of pdb traceback display Follow-Ups: Date: 2000-Aug-13 20:15 By: nowonder Comment: There is a detailed description in the patch. ------------------------------------------------------- Date: 2000-Aug-15 10:55 By: tim_one Comment: Reassigned to Guido in Jeremy's absence, cuz I never use pdb but know Guido has at least once . Please review or pass on to someone else. ------------------------------------------------------- Date: 2000-Aug-17 12:36 By: gvanrossum Comment: I like the idea fine, but the command name "scaletb" sucks. Once a better name is coined Ken should get checkin permissions if he doesn't already have them, so he can check it in. (Isn't it ironic that Ken, who enjoys naming debates so much, came up with a sucky name? :-) Possibly a better name could include "control" (or an abbreviation) instead of "scale"? ------------------------------------------------------- Date: 2000-Aug-21 16:59 By: tim_one Comment: Ken, are you going to repsond to Guido's comments? And do you want developer privileges? ------------------------------------------------------- Date: 2000-Aug-27 09:57 By: klm Comment: Sorry about not responding more promptly. Actually, i got the email for guido's patch comment, and wasn't sure who to contact about getting checkin privileges, so was waiting for a moment to look around a bit to track that down and think things through. It so happens (1) i didn't get the moment until this morning (!), and (2) i must have missed tim's subsequent comment in my email box, because this is the first i saw of it. I do seem to have cvs ssh access, now, and have an alternate name to suggest. I'd be happy to arrive at some agreement on a name and then check in the changes. My current suggestion is 'limit_tb', with no abbreviation. I think this name is a lot more self-evident than scaletb, and a lot more specific than something like 'control_tb'. I can see objections to this, and am open to other suggestions. (If you insist on 'control_tb' or somesuch, fine.) Though this is Just A Name, there are some complications arriving at a name that fits well with the pdb commands. First, none of the other pdb command names are very long, so while "limit_traceback" would be most clear, it would be out of place. And cumbersome. Inclusion of an underscore in a pdb command name is, itself, unprecedented, but that helps avoid confusion with the "tb" of 'tbreak' (where "tb" => "temporary break"). Perhaps the "tb" collision is enough reason to spell out "traceback" - but incongruous and cumbersome, see above. Perhaps the most comprehensive solution would be to have a pdb "set" command, to set operational options, and then have a "set traceback_limit". That seems much too elaborate for a single option. It also seems like overkill even for several options, if there's no persistence to the pdb configuration - too much for settings that only last for a python session. While there may or may not be good reasons to have a persistent mechanism, i think the limit_tb command would be quite useful without it - people can enlarge the tb size once they see it's necessary, and reevoke it. So i'm for 'limit_tb', but open to other suggestions, willing to accept an edict if that means i can just check this in (or try another approach). (I think i'm set to do the checkin - i assume my addition to the python project developers roster means i have the privileges, and i've applied the patch to an ssh checkout, ready and sort of eager to try the checkin...) Ken ------------------------------------------------------- Date: 2000-Aug-31 14:36 By: jhylton Comment: Ken has disappeared ------------------------------------------------------- Date: 2000-Sep-07 17:14 By: klm Comment: Here's a new patch using "limit_tb" instead of "scaletb" as the name. I also realize that the changes to repr - presentation limits added as parameters on __init__, plus a "multiplication factor" to make it easy to change from standard limits with one easy value - ought to be documented in the repr standard library docs. I'll pursue that, if necessary, but wanted to see if this new name, and the rest of the patch, passes muster. As jeremy suggested, i will setting the "assigned to" to guido, so he judge it. (Except i don't see how to reassign - perhaps that comes next, after submitting this?? Murgh.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100947&group_id=5470 From noreply@sourceforge.net Thu Sep 14 19:25:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 11:25:56 -0700 Subject: [Patches] [Patch #101121] cosmetic cleanup of cgi.py, using Guido's style conventions Message-ID: <200009141825.LAA13316@bush.i.sourceforge.net> Patch #101121 has been updated. Project: Category: library Status: Open Summary: cosmetic cleanup of cgi.py, using Guido's style conventions Follow-Ups: Date: 2000-Aug-08 13:37 By: ping Comment: This is an immediate follow-on to #101120 (i just wanted to keep the semantic and non-semantic changes separate). ------------------------------------------------------- Date: 2000-Aug-15 15:06 By: tim_one Comment: I'm not sure what you mean by "follow-on". If this patch is *independent* of 101120, just Accept it yourself and check it in -- there's no need to go thru a review process for mechanical cleanup. Assigning to you on that basis. Ah, and you *can* check it in, in about 6 hours: you've been added to the Python project as a Developer. That means I get to assign patches to you for review, too From noreply@sourceforge.net Fri Sep 15 00:57:20 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 16:57:20 -0700 Subject: [Patches] [Patch #101433] Fix for 110845: Check struct short and byte ranges Message-ID: <200009142357.QAA26133@bush.i.sourceforge.net> Patch #101433 has been updated. Project: Category: library Status: Accepted Summary: Fix for 110845: Check struct short and byte ranges Follow-Ups: Date: 2000-Sep-14 16:57 By: tmick Comment: Instead of 0 - 65536 and -32768 - +32767 you should use USHRT_MIN, USHRT_MAX, SHRT_MIN, and SHRT_MAX. I may the names slightly wrong but they are standard C things (I think). They are being used in Python/getargs.c. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101433&group_id=5470 From noreply@sourceforge.net Fri Sep 15 05:37:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 21:37:08 -0700 Subject: [Patches] [Patch #101514] Remove references to self._source Message-ID: <200009150437.VAA03462@bush.i.sourceforge.net> Patch #101514 has been updated. Project: Category: XML Status: Open Summary: Remove references to self._source Follow-Ups: Date: 2000-Sep-14 12:37 By: prescod Comment: (this update to the patch makes fewer changes to the original code than the original patch based on the philosophy that it will be easier for Lars to apply his fixes if the code changes as little as possible) Read the comment about InputSource in the patch. All references to self._source are removed. Remove special case handling of streams versus strings (done in xmlreader now). ------------------------------------------------------- Date: 2000-Sep-14 13:49 By: fdrake Comment: Please don't comment out the lines; just remove them. CVS will keep the history of what happened just fine. Please make this mechanical change and check it in. ------------------------------------------------------- Date: 2000-Sep-14 21:37 By: fdrake Comment: Based on email from Paul, let's wait and let Lars say something about this one. Re-opened and assigned to Lars for review. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101514&group_id=5470 From noreply@sourceforge.net Fri Sep 15 05:55:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 21:55:15 -0700 Subject: [Patches] [Patch #101517] Fix for Bug 114333 (only reported bug in minidom) Message-ID: <200009150455.VAA21709@delerium.i.sourceforge.net> Patch #101517 has been updated. Project: Category: XML Status: Open Summary: Fix for Bug 114333 (only reported bug in minidom) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101517&group_id=5470 From noreply@sourceforge.net Fri Sep 15 05:56:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 21:56:18 -0700 Subject: [Patches] [Patch #101517] Fix for Bug 114333 (only reported bug in minidom) Message-ID: <200009150456.VAA21718@delerium.i.sourceforge.net> Patch #101517 has been updated. Project: Category: XML Status: Open Summary: Fix for Bug 114333 (only reported bug in minidom) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101517&group_id=5470 From noreply@sourceforge.net Fri Sep 15 06:03:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 22:03:40 -0700 Subject: [Patches] [Patch #101496] Support switches -h and -V (help & version) Message-ID: <200009150503.WAA04268@bush.i.sourceforge.net> Patch #101496 has been updated. Project: Category: core (C code) Status: Accepted Summary: Support switches -h and -V (help & version) Follow-Ups: Date: 2000-Sep-14 07:18 By: fdrake Comment: This looks good to me; fix Misc/python.man as well, then check it in. ------------------------------------------------------- Date: 2000-Sep-14 22:03 By: bwarsaw Comment: Jeremy, please rule: can this go into 2.0beta2? If so, reassign back to me and I'll check it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101496&group_id=5470 From noreply@sourceforge.net Fri Sep 15 07:58:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Sep 2000 23:58:38 -0700 Subject: [Patches] [Patch #101425] Fix for 110598: support \r in py_compile Message-ID: <200009150658.XAA25665@delerium.i.sourceforge.net> Patch #101425 has been updated. Project: Category: library Status: Closed Summary: Fix for 110598: support \r in py_compile ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101425&group_id=5470 From noreply@sourceforge.net Fri Sep 15 08:08:30 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 00:08:30 -0700 Subject: [Patches] [Patch #101509] Fix for 114424: PyTuple_Resize buggy with cyclic gc Message-ID: <200009150708.AAA26046@delerium.i.sourceforge.net> Patch #101509 has been updated. Project: Category: core (C code) Status: Closed Summary: Fix for 114424: PyTuple_Resize buggy with cyclic gc Follow-Ups: Date: 2000-Sep-14 11:28 By: nascheme Comment: This looks like a real bug. If realloc returns a new pointer then using g is wrong. I'm not sure about this patch though. I think the realloc line should be changed to: g = (PyTupleObject *) PyObject_REALLOC((char *)g, ...) ------------------------------------------------------- Date: 2000-Sep-14 11:53 By: loewis Comment: You are right. I've uploaded a revised patch. ------------------------------------------------------- Date: 2000-Sep-15 00:08 By: loewis Comment: Committed as instructed by /F. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101509&group_id=5470 From noreply@sourceforge.net Fri Sep 15 09:12:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 01:12:25 -0700 Subject: [Patches] [Patch #101433] Fix for 110845: Check struct short and byte ranges Message-ID: <200009150812.BAA28248@delerium.i.sourceforge.net> Patch #101433 has been updated. Project: Category: library Status: Closed Summary: Fix for 110845: Check struct short and byte ranges Follow-Ups: Date: 2000-Sep-14 16:57 By: tmick Comment: Instead of 0 - 65536 and -32768 - +32767 you should use USHRT_MIN, USHRT_MAX, SHRT_MIN, and SHRT_MAX. I may the names slightly wrong but they are standard C things (I think). They are being used in Python/getargs.c. ------------------------------------------------------- Date: 2000-Sep-15 01:12 By: loewis Comment: I've changed the patch to use symbolic constants. Since there is no USHRT_MIN in ISO C, I don't use this constant. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101433&group_id=5470 From noreply@sourceforge.net Fri Sep 15 10:17:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 02:17:15 -0700 Subject: [Patches] [Patch #101507] add 'punctuation' and 'printable' consts. to stropmodule.c Message-ID: <200009150917.CAA12535@bush.i.sourceforge.net> Patch #101507 has been updated. Project: Category: core (C code) Status: Open Summary: add 'punctuation' and 'printable' consts. to stropmodule.c Follow-Ups: Date: 2000-Sep-14 07:15 By: fdrake Comment: Why not just define these as constants in string.py? That would be more usable since strop is not necessarily available, and can be considered an implementation detail at best. Also, note that ispunct() and isprint() are available in the curses.ascii module. ------------------------------------------------------- Date: 2000-Sep-14 09:40 By: fdrake Comment: Response from Richard Mortier: Ah -- this was originally generated because I wanted to use it in Python 1.5.2 -- didn't realise later versions had curses.ascii Not defining them in string.py was because I wanted the behaviour of isprint() (in particular). ------------------------------------------------------- Date: 2000-Sep-14 09:43 By: fdrake Comment: My response to Richard: But why not just take the resulting value from your patch and add a couple of lines to Lib/string.py: printable = "..." punctuation = "..." If you can create an updated patch with this, and add a comment to the SourceForge interface explaining why these would be useful, we can consider it. ------------------------------------------------------- Date: 2000-Sep-15 02:17 By: rmm1002 Comment: --- string.py.old Sun Jul 16 13:04:30 2000 +++ string.py Fri Sep 15 10:06:58 2000 @@ -25,6 +25,8 @@ digits = '0123456789' hexdigits = digits + 'abcdef' + 'ABCDEF' octdigits = '01234567' +punctuaction = """!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~""" +printable = digits + letters + punctuation + whitespace # Case conversion helpers _idmap = '' ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101507&group_id=5470 From noreply@sourceforge.net Fri Sep 15 10:27:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 02:27:46 -0700 Subject: [Patches] [Patch #101507] add 'punctuation' and 'printable' consts. to stropmodule.c Message-ID: <200009150927.CAA12886@bush.i.sourceforge.net> Patch #101507 has been updated. Project: Category: core (C code) Status: Open Summary: add 'punctuation' and 'printable' consts. to stropmodule.c Follow-Ups: Date: 2000-Sep-14 07:15 By: fdrake Comment: Why not just define these as constants in string.py? That would be more usable since strop is not necessarily available, and can be considered an implementation detail at best. Also, note that ispunct() and isprint() are available in the curses.ascii module. ------------------------------------------------------- Date: 2000-Sep-14 09:40 By: fdrake Comment: Response from Richard Mortier: Ah -- this was originally generated because I wanted to use it in Python 1.5.2 -- didn't realise later versions had curses.ascii Not defining them in string.py was because I wanted the behaviour of isprint() (in particular). ------------------------------------------------------- Date: 2000-Sep-14 09:43 By: fdrake Comment: My response to Richard: But why not just take the resulting value from your patch and add a couple of lines to Lib/string.py: printable = "..." punctuation = "..." If you can create an updated patch with this, and add a comment to the SourceForge interface explaining why these would be useful, we can consider it. ------------------------------------------------------- Date: 2000-Sep-15 02:17 By: rmm1002 Comment: --- string.py.old Sun Jul 16 13:04:30 2000 +++ string.py Fri Sep 15 10:06:58 2000 @@ -25,6 +25,8 @@ digits = '0123456789' hexdigits = digits + 'abcdef' + 'ABCDEF' octdigits = '01234567' +punctuaction = """!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~""" +printable = digits + letters + punctuation + whitespace # Case conversion helpers _idmap = '' ------------------------------------------------------- Date: 2000-Sep-15 02:27 By: rmm1002 Comment: now added to Lib/string.py instead of stropmodule.c; useful for a couple of scripts I was writing for checking output before printing it -- in general, given that the string module contains the constants "letters", "digits" et al, it seems natural that it should contain "punctuation" (and "printable" IMO, but given curses.ascii maybe not) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101507&group_id=5470 From noreply@sourceforge.net Fri Sep 15 11:16:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 03:16:00 -0700 Subject: [Patches] [Patch #101527] ustr Message-ID: <200009151016.DAA32728@delerium.i.sourceforge.net> Patch #101527 has been updated. Project: Category: None Status: Open Summary: ustr ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101527&group_id=5470 From noreply@sourceforge.net Fri Sep 15 11:17:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 03:17:09 -0700 Subject: [Patches] [Patch #101527] ustr Message-ID: <200009151017.DAA00305@delerium.i.sourceforge.net> Patch #101527 has been updated. Project: Category: None Status: Open Summary: ustr Follow-Ups: Date: 2000-Sep-15 03:17 By: htrd Comment: In July on i18n-sig, we discussed the need for a builtin function like "str" but which could return any string-like object. Guido endorsed the idea http://www.python.org/pipermail/i18n-sig/2000-July/000338.html but no patch has been submitted. I know its too late to add this as a builtin for 2.0. Is it too late to add it to the string module? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101527&group_id=5470 From noreply@sourceforge.net Fri Sep 15 12:03:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 04:03:57 -0700 Subject: [Patches] [Patch #101512] Support parsing of already opened file objects Message-ID: <200009151103.EAA16374@bush.i.sourceforge.net> Patch #101512 has been updated. Project: Category: XML Status: Open Summary: Support parsing of already opened file objects Follow-Ups: Date: 2000-Sep-14 11:15 By: jhylton Comment: I don't particularly care for this interface change. It appears that the parser will close the file if passed as an argument. Since the parser did not open the file, it should not close it. It seems to me that this feature should be a separate method. Also, there seem to be a lot of style problems with this code. There is inconsistent use of whitespace around ()s and =s. It should be consistent above all! And it should use the approved Python style. ------------------------------------------------------- Date: 2000-Sep-14 12:21 By: prescod Comment: This isn't an interface change, it just makes the interface work the way it says it does. If fixes a FIXME. A separate method is a good idea but it would have to be agreed upon by the xml-sig (or at least implemented by Lars, the main SAX maintainer). I see that as part of the larger refactoring that Lars is doing. I'm not clear what line of code closes the file. It looks to me like it just goes out of scope still open. ------------------------------------------------------- Date: 2000-Sep-14 14:08 By: fdrake Comment: I'm hesitant to approve this myself; I don't like the overloading. (Though I agree that this simply brings the implementation into line with the documentation, such as it is.) The Java equivelent uses an overloaded parse() method, but Java provides direct support for this in the language definition. I think the Python SAX2 definition should provide separate methods. Let's wait for Lars to weigh in on the API issues. ------------------------------------------------------- Date: 2000-Sep-15 04:03 By: gvanrossum Comment: I would approve this if it took care of Jeremy's concern: if the file is opened by the caller, the callee should not close it. Given that Java overloads parse(), the Python approach of testing for a file is fine; I don't think it's necessary to dd a new method. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101512&group_id=5470 From noreply@sourceforge.net Fri Sep 15 12:52:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 04:52:17 -0700 Subject: [Patches] [Patch #101496] Support switches -h and -V (help & version) Message-ID: <200009151152.EAA18125@bush.i.sourceforge.net> Patch #101496 has been updated. Project: Category: core (C code) Status: Open Summary: Support switches -h and -V (help & version) Follow-Ups: Date: 2000-Sep-14 07:18 By: fdrake Comment: This looks good to me; fix Misc/python.man as well, then check it in. ------------------------------------------------------- Date: 2000-Sep-14 22:03 By: bwarsaw Comment: Jeremy, please rule: can this go into 2.0beta2? If so, reassign back to me and I'll check it in. ------------------------------------------------------- Date: 2000-Sep-15 04:52 By: gvanrossum Comment: Why does -h print the usage and then continue to function, while -V prints the version and exits? (Should it check that there are no other command line args before exiting???) Note that you also need to fix Misc/python.man ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101496&group_id=5470 From noreply@sourceforge.net Fri Sep 15 14:16:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 06:16:58 -0700 Subject: [Patches] [Patch #101527] ustr Message-ID: <200009151316.GAA06637@delerium.i.sourceforge.net> Patch #101527 has been updated. Project: Category: None Status: Postponed Summary: ustr Follow-Ups: Date: 2000-Sep-15 03:17 By: htrd Comment: In July on i18n-sig, we discussed the need for a builtin function like "str" but which could return any string-like object. Guido endorsed the idea http://www.python.org/pipermail/i18n-sig/2000-July/000338.html but no patch has been submitted. I know its too late to add this as a builtin for 2.0. Is it too late to add it to the string module? ------------------------------------------------------- Date: 2000-Sep-15 06:16 By: gvanrossum Comment: I think we should not do this now. A feature freeze is a feature freeze. :-) Let's see if the need really exists once 2.0 is released and then we can add it to 2.1. I'm sure there are lots of other things that we find would be useful to add, once there's some real experience using the new Unicode stuff. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101527&group_id=5470 From noreply@sourceforge.net Fri Sep 15 14:25:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 06:25:06 -0700 Subject: [Patches] [Patch #101529] urllib and redirects Message-ID: <200009151325.GAA21461@bush.i.sourceforge.net> Patch #101529 has been updated. Project: Category: None Status: Open Summary: urllib and redirects ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101529&group_id=5470 From noreply@sourceforge.net Fri Sep 15 14:25:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 06:25:29 -0700 Subject: [Patches] [Patch #101530] urllib and redirects Message-ID: <200009151325.GAA21465@bush.i.sourceforge.net> Patch #101530 has been updated. Project: Category: None Status: Open Summary: urllib and redirects ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101530&group_id=5470 From noreply@sourceforge.net Fri Sep 15 14:28:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 06:28:43 -0700 Subject: [Patches] [Patch #101529] urllib and redirects Message-ID: <200009151328.GAA21542@bush.i.sourceforge.net> Patch #101529 has been updated. Project: Category: None Status: Open Summary: urllib and redirects Follow-Ups: Date: 2000-Sep-15 06:28 By: htrd Comment: httplib is sometimes closing its file earlier than before. This confuses urllib, which expects to have to close the file itself. This patch fixes the behaviour in urllib, although I am not sure that the real bug isnt the change in httplib. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101529&group_id=5470 From noreply@sourceforge.net Fri Sep 15 14:32:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 06:32:10 -0700 Subject: [Patches] [Patch #101529] urllib and redirects Message-ID: <200009151332.GAA21735@bush.i.sourceforge.net> Patch #101529 has been updated. Project: Category: library Status: Open Summary: urllib and redirects Follow-Ups: Date: 2000-Sep-15 06:28 By: htrd Comment: httplib is sometimes closing its file earlier than before. This confuses urllib, which expects to have to close the file itself. This patch fixes the behaviour in urllib, although I am not sure that the real bug isnt the change in httplib. ------------------------------------------------------- Date: 2000-Sep-15 06:32 By: jhylton Comment: Ah, serendipity. I'm debugging the same problem right now! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101529&group_id=5470 From noreply@sourceforge.net Fri Sep 15 14:34:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 06:34:23 -0700 Subject: [Patches] [Patch #101530] urllib and redirects Message-ID: <200009151334.GAA21761@bush.i.sourceforge.net> Patch #101530 has been updated. Project: Category: None Status: Open Summary: urllib and redirects Follow-Ups: Date: 2000-Sep-15 06:34 By: htrd Comment: Damn browser refreshes. Please delete this duplicate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101530&group_id=5470 From noreply@sourceforge.net Fri Sep 15 14:42:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 06:42:00 -0700 Subject: [Patches] [Patch #101529] urllib and redirects Message-ID: <200009151342.GAA07615@delerium.i.sourceforge.net> Patch #101529 has been updated. Project: Category: library Status: Open Summary: urllib and redirects Follow-Ups: Date: 2000-Sep-15 06:28 By: htrd Comment: httplib is sometimes closing its file earlier than before. This confuses urllib, which expects to have to close the file itself. This patch fixes the behaviour in urllib, although I am not sure that the real bug isnt the change in httplib. ------------------------------------------------------- Date: 2000-Sep-15 06:32 By: jhylton Comment: Ah, serendipity. I'm debugging the same problem right now! ------------------------------------------------------- Date: 2000-Sep-15 06:42 By: gvanrossum Comment: Of course this should be fixed in httplib. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101529&group_id=5470 From noreply@sourceforge.net Fri Sep 15 14:53:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 06:53:10 -0700 Subject: [Patches] [Patch #101512] Support parsing of already opened file objects Message-ID: <200009151353.GAA08006@delerium.i.sourceforge.net> Patch #101512 has been updated. Project: Category: XML Status: Open Summary: Support parsing of already opened file objects Follow-Ups: Date: 2000-Sep-14 11:15 By: jhylton Comment: I don't particularly care for this interface change. It appears that the parser will close the file if passed as an argument. Since the parser did not open the file, it should not close it. It seems to me that this feature should be a separate method. Also, there seem to be a lot of style problems with this code. There is inconsistent use of whitespace around ()s and =s. It should be consistent above all! And it should use the approved Python style. ------------------------------------------------------- Date: 2000-Sep-14 12:21 By: prescod Comment: This isn't an interface change, it just makes the interface work the way it says it does. If fixes a FIXME. A separate method is a good idea but it would have to be agreed upon by the xml-sig (or at least implemented by Lars, the main SAX maintainer). I see that as part of the larger refactoring that Lars is doing. I'm not clear what line of code closes the file. It looks to me like it just goes out of scope still open. ------------------------------------------------------- Date: 2000-Sep-14 14:08 By: fdrake Comment: I'm hesitant to approve this myself; I don't like the overloading. (Though I agree that this simply brings the implementation into line with the documentation, such as it is.) The Java equivelent uses an overloaded parse() method, but Java provides direct support for this in the language definition. I think the Python SAX2 definition should provide separate methods. Let's wait for Lars to weigh in on the API issues. ------------------------------------------------------- Date: 2000-Sep-15 04:03 By: gvanrossum Comment: I would approve this if it took care of Jeremy's concern: if the file is opened by the caller, the callee should not close it. Given that Java overloads parse(), the Python approach of testing for a file is fine; I don't think it's necessary to dd a new method. ------------------------------------------------------- Date: 2000-Sep-15 06:53 By: prescod Comment: I believe Jeremy to be wrong. If you do a "grep" in the xml/sig directory you'll find that files are never closed. They just go out of scope. If we opened the file then it will close when it goes out of scope. If the caller opened the file, it will close when they throw away their last reference to it. The wonders of reference counting! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101512&group_id=5470 From noreply@sourceforge.net Fri Sep 15 14:56:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 06:56:56 -0700 Subject: [Patches] [Patch #101512] Support parsing of already opened file objects Message-ID: <200009151356.GAA08184@delerium.i.sourceforge.net> Patch #101512 has been updated. Project: Category: XML Status: Open Summary: Support parsing of already opened file objects Follow-Ups: Date: 2000-Sep-14 11:15 By: jhylton Comment: I don't particularly care for this interface change. It appears that the parser will close the file if passed as an argument. Since the parser did not open the file, it should not close it. It seems to me that this feature should be a separate method. Also, there seem to be a lot of style problems with this code. There is inconsistent use of whitespace around ()s and =s. It should be consistent above all! And it should use the approved Python style. ------------------------------------------------------- Date: 2000-Sep-14 12:21 By: prescod Comment: This isn't an interface change, it just makes the interface work the way it says it does. If fixes a FIXME. A separate method is a good idea but it would have to be agreed upon by the xml-sig (or at least implemented by Lars, the main SAX maintainer). I see that as part of the larger refactoring that Lars is doing. I'm not clear what line of code closes the file. It looks to me like it just goes out of scope still open. ------------------------------------------------------- Date: 2000-Sep-14 14:08 By: fdrake Comment: I'm hesitant to approve this myself; I don't like the overloading. (Though I agree that this simply brings the implementation into line with the documentation, such as it is.) The Java equivelent uses an overloaded parse() method, but Java provides direct support for this in the language definition. I think the Python SAX2 definition should provide separate methods. Let's wait for Lars to weigh in on the API issues. ------------------------------------------------------- Date: 2000-Sep-15 04:03 By: gvanrossum Comment: I would approve this if it took care of Jeremy's concern: if the file is opened by the caller, the callee should not close it. Given that Java overloads parse(), the Python approach of testing for a file is fine; I don't think it's necessary to dd a new method. ------------------------------------------------------- Date: 2000-Sep-15 06:53 By: prescod Comment: I believe Jeremy to be wrong. If you do a "grep" in the xml/sig directory you'll find that files are never closed. They just go out of scope. If we opened the file then it will close when it goes out of scope. If the caller opened the file, it will close when they throw away their last reference to it. The wonders of reference counting! ------------------------------------------------------- Date: 2000-Sep-15 06:56 By: jhylton Comment: It sounds like the code has the opposite sort of bug, then. It opens file and does not explicitly close them. The code should not depend on the reference counting mechanism to close files. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101512&group_id=5470 From noreply@sourceforge.net Fri Sep 15 14:58:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 06:58:52 -0700 Subject: [Patches] [Patch #101517] Fix for Bug 114333 (only reported bug in minidom) Message-ID: <200009151358.GAA22752@bush.i.sourceforge.net> Patch #101517 has been updated. Project: Category: XML Status: Accepted Summary: Fix for Bug 114333 (only reported bug in minidom) Follow-Ups: Date: 2000-Sep-15 06:58 By: fdrake Comment: Looks good, check it in. You should go through the code and transform "func( a, b )" to "func(a, b)", and "x=foo..." to "x = foo..." to conform to the Python style guide (http://www.python.org/doc/essys/styleguide.html). This should be a separate checkin. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101517&group_id=5470 From noreply@sourceforge.net Fri Sep 15 15:02:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 07:02:59 -0700 Subject: [Patches] [Patch #101530] urllib and redirects Message-ID: <200009151402.HAA22919@bush.i.sourceforge.net> Patch #101530 has been updated. Project: Category: library Status: Deleted Summary: urllib and redirects Follow-Ups: Date: 2000-Sep-15 06:34 By: htrd Comment: Damn browser refreshes. Please delete this duplicate. ------------------------------------------------------- Date: 2000-Sep-15 07:02 By: fdrake Comment: Duplicate; deleted. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101530&group_id=5470 From noreply@sourceforge.net Fri Sep 15 15:17:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 07:17:03 -0700 Subject: [Patches] [Patch #101388] Backward compatibility hook Message-ID: <200009151417.HAA23776@bush.i.sourceforge.net> Patch #101388 has been updated. Project: Category: documentation Status: Open Summary: Backward compatibility hook Follow-Ups: Date: 2000-Sep-01 07:41 By: jhylton Comment: same deal: postponed for now, but may be considered post 2.0b1 ------------------------------------------------------- Date: 2000-Sep-15 07:17 By: fdrake Comment: The test using sys.hexversion may be more readable if sys.version_info is used instead: if sys.version_info < (2, 0): ... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101388&group_id=5470 From noreply@sourceforge.net Fri Sep 15 15:21:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 07:21:13 -0700 Subject: [Patches] [Patch #101416] coax _sre.c into using Py_GetRecursionLimit() Message-ID: <200009151421.HAA23979@bush.i.sourceforge.net> Patch #101416 has been updated. Project: Category: Modules Status: Open Summary: coax _sre.c into using Py_GetRecursionLimit() Follow-Ups: Date: 2000-Sep-04 09:02 By: montanaro Comment: seems obvious that Fredrik should be the one to handle this... ------------------------------------------------------- Date: 2000-Sep-15 07:21 By: fdrake Comment: The declaration of rlimit should be wrapped in #ifdef USE_RECURSION_LIMIT / #endif, since it isn't used otherwise. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101416&group_id=5470 From noreply@sourceforge.net Fri Sep 15 15:29:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 07:29:49 -0700 Subject: [Patches] [Patch #101512] Support parsing of already opened file objects Message-ID: <200009151429.HAA09344@delerium.i.sourceforge.net> Patch #101512 has been updated. Project: Category: XML Status: Open Summary: Support parsing of already opened file objects Follow-Ups: Date: 2000-Sep-14 11:15 By: jhylton Comment: I don't particularly care for this interface change. It appears that the parser will close the file if passed as an argument. Since the parser did not open the file, it should not close it. It seems to me that this feature should be a separate method. Also, there seem to be a lot of style problems with this code. There is inconsistent use of whitespace around ()s and =s. It should be consistent above all! And it should use the approved Python style. ------------------------------------------------------- Date: 2000-Sep-14 12:21 By: prescod Comment: This isn't an interface change, it just makes the interface work the way it says it does. If fixes a FIXME. A separate method is a good idea but it would have to be agreed upon by the xml-sig (or at least implemented by Lars, the main SAX maintainer). I see that as part of the larger refactoring that Lars is doing. I'm not clear what line of code closes the file. It looks to me like it just goes out of scope still open. ------------------------------------------------------- Date: 2000-Sep-14 14:08 By: fdrake Comment: I'm hesitant to approve this myself; I don't like the overloading. (Though I agree that this simply brings the implementation into line with the documentation, such as it is.) The Java equivelent uses an overloaded parse() method, but Java provides direct support for this in the language definition. I think the Python SAX2 definition should provide separate methods. Let's wait for Lars to weigh in on the API issues. ------------------------------------------------------- Date: 2000-Sep-15 04:03 By: gvanrossum Comment: I would approve this if it took care of Jeremy's concern: if the file is opened by the caller, the callee should not close it. Given that Java overloads parse(), the Python approach of testing for a file is fine; I don't think it's necessary to dd a new method. ------------------------------------------------------- Date: 2000-Sep-15 06:53 By: prescod Comment: I believe Jeremy to be wrong. If you do a "grep" in the xml/sig directory you'll find that files are never closed. They just go out of scope. If we opened the file then it will close when it goes out of scope. If the caller opened the file, it will close when they throw away their last reference to it. The wonders of reference counting! ------------------------------------------------------- Date: 2000-Sep-15 06:56 By: jhylton Comment: It sounds like the code has the opposite sort of bug, then. It opens file and does not explicitly close them. The code should not depend on the reference counting mechanism to close files. ------------------------------------------------------- Date: 2000-Sep-15 07:29 By: prescod Comment: The word bug is too strong when all the module does is depend on documented Python features. Allowing auto-closing of files is one of the major arguments for Python's reference counting (according to the Python FAQ) and an advantage of Python over Java et al. If you do explicit closing you reintroduce the same lifetime issues that make pointer handling such a hassle in C++. In this particular case, the lifetime of the file object is pretty easy to track (barring funny stuff) so adding a close would be relatively easy and would make portability to JPython easier. I would like to hear what the BeOpen concensus is so that I can add it to my personal style guide. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101512&group_id=5470 From noreply@sourceforge.net Fri Sep 15 15:31:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 07:31:21 -0700 Subject: [Patches] [Patch #101496] Support switches -h and -V (help & version) Message-ID: <200009151431.HAA24421@bush.i.sourceforge.net> Patch #101496 has been updated. Project: Category: core (C code) Status: Open Summary: Support switches -h and -V (help & version) Follow-Ups: Date: 2000-Sep-14 07:18 By: fdrake Comment: This looks good to me; fix Misc/python.man as well, then check it in. ------------------------------------------------------- Date: 2000-Sep-14 22:03 By: bwarsaw Comment: Jeremy, please rule: can this go into 2.0beta2? If so, reassign back to me and I'll check it in. ------------------------------------------------------- Date: 2000-Sep-15 04:52 By: gvanrossum Comment: Why does -h print the usage and then continue to function, while -V prints the version and exits? (Should it check that there are no other command line args before exiting???) Note that you also need to fix Misc/python.man ------------------------------------------------------- Date: 2000-Sep-15 07:31 By: bwarsaw Comment: Yes, -h exits too. usage() calls exit(). Here's an updated patch that includes mods to Misc/python.man ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101496&group_id=5470 From noreply@sourceforge.net Fri Sep 15 15:52:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 07:52:10 -0700 Subject: [Patches] [Patch #101512] Support parsing of already opened file objects Message-ID: <200009151452.HAA25252@bush.i.sourceforge.net> Patch #101512 has been updated. Project: Category: XML Status: Open Summary: Support parsing of already opened file objects Follow-Ups: Date: 2000-Sep-14 11:15 By: jhylton Comment: I don't particularly care for this interface change. It appears that the parser will close the file if passed as an argument. Since the parser did not open the file, it should not close it. It seems to me that this feature should be a separate method. Also, there seem to be a lot of style problems with this code. There is inconsistent use of whitespace around ()s and =s. It should be consistent above all! And it should use the approved Python style. ------------------------------------------------------- Date: 2000-Sep-14 12:21 By: prescod Comment: This isn't an interface change, it just makes the interface work the way it says it does. If fixes a FIXME. A separate method is a good idea but it would have to be agreed upon by the xml-sig (or at least implemented by Lars, the main SAX maintainer). I see that as part of the larger refactoring that Lars is doing. I'm not clear what line of code closes the file. It looks to me like it just goes out of scope still open. ------------------------------------------------------- Date: 2000-Sep-14 14:08 By: fdrake Comment: I'm hesitant to approve this myself; I don't like the overloading. (Though I agree that this simply brings the implementation into line with the documentation, such as it is.) The Java equivelent uses an overloaded parse() method, but Java provides direct support for this in the language definition. I think the Python SAX2 definition should provide separate methods. Let's wait for Lars to weigh in on the API issues. ------------------------------------------------------- Date: 2000-Sep-15 04:03 By: gvanrossum Comment: I would approve this if it took care of Jeremy's concern: if the file is opened by the caller, the callee should not close it. Given that Java overloads parse(), the Python approach of testing for a file is fine; I don't think it's necessary to dd a new method. ------------------------------------------------------- Date: 2000-Sep-15 06:53 By: prescod Comment: I believe Jeremy to be wrong. If you do a "grep" in the xml/sig directory you'll find that files are never closed. They just go out of scope. If we opened the file then it will close when it goes out of scope. If the caller opened the file, it will close when they throw away their last reference to it. The wonders of reference counting! ------------------------------------------------------- Date: 2000-Sep-15 06:56 By: jhylton Comment: It sounds like the code has the opposite sort of bug, then. It opens file and does not explicitly close them. The code should not depend on the reference counting mechanism to close files. ------------------------------------------------------- Date: 2000-Sep-15 07:29 By: prescod Comment: The word bug is too strong when all the module does is depend on documented Python features. Allowing auto-closing of files is one of the major arguments for Python's reference counting (according to the Python FAQ) and an advantage of Python over Java et al. If you do explicit closing you reintroduce the same lifetime issues that make pointer handling such a hassle in C++. In this particular case, the lifetime of the file object is pretty easy to track (barring funny stuff) so adding a close would be relatively easy and would make portability to JPython easier. I would like to hear what the BeOpen concensus is so that I can add it to my personal style guide. ------------------------------------------------------- Date: 2000-Sep-15 07:52 By: gvanrossum Comment: BeOpen doesn't enter into it. :-) PythonLabs is what counts. Consensus is had has been as Jeremy says: iff you open a file, you should close it. Note: adding close() should be a separate patch. Fred: you can accept this one once the close() patch is in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101512&group_id=5470 From noreply@sourceforge.net Fri Sep 15 16:05:14 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 08:05:14 -0700 Subject: [Patches] [Patch #101531] Fix for GC bug #113812 Message-ID: <200009151505.IAA10876@delerium.i.sourceforge.net> Patch #101531 has been updated. Project: Category: core (C code) Status: Open Summary: Fix for GC bug #113812 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101531&group_id=5470 From noreply@sourceforge.net Fri Sep 15 16:16:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 08:16:31 -0700 Subject: [Patches] [Patch #101486] Unexpected Evaluation of Expressions from Pickle Patch Message-ID: <200009151516.IAA26271@bush.i.sourceforge.net> Patch #101486 has been updated. Project: Category: Modules Status: Rejected Summary: Unexpected Evaluation of Expressions from Pickle Patch Follow-Ups: Date: 2000-Sep-15 08:16 By: jhylton Comment: used different fix for this bug ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101486&group_id=5470 From noreply@sourceforge.net Fri Sep 15 16:26:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 08:26:25 -0700 Subject: [Patches] [Patch #101416] coax _sre.c into using Py_GetRecursionLimit() Message-ID: <200009151526.IAA11687@delerium.i.sourceforge.net> Patch #101416 has been updated. Project: Category: Modules Status: Open Summary: coax _sre.c into using Py_GetRecursionLimit() Follow-Ups: Date: 2000-Sep-04 09:02 By: montanaro Comment: seems obvious that Fredrik should be the one to handle this... ------------------------------------------------------- Date: 2000-Sep-15 07:21 By: fdrake Comment: The declaration of rlimit should be wrapped in #ifdef USE_RECURSION_LIMIT / #endif, since it isn't used otherwise. ------------------------------------------------------- Date: 2000-Sep-15 08:26 By: montanaro Comment: thanks - new version adds the appropriate ifdef ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101416&group_id=5470 From noreply@sourceforge.net Fri Sep 15 17:41:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 09:41:16 -0700 Subject: [Patches] [Patch #101233] PyModule_AddObject() and friends Message-ID: <200009151641.JAA29471@bush.i.sourceforge.net> Patch #101233 has been updated. Project: Category: core (C code) Status: Open Summary: PyModule_AddObject() and friends Follow-Ups: Date: 2000-Aug-19 10:17 By: marangoz Comment: Looks good. BDFL need to Pronounce on API issues. What amount of changes would this imply in the distrib? Have patch? (the names could be tuned later directly in the patch ) ------------------------------------------------------- Date: 2000-Aug-19 21:31 By: tim_one Comment: Assigned to Guido because, as Vlad says, he needs to Prounounce on the idea. Guido, the point here is to provide a single implementation to replace all the repeated and inconsistent functions and macros that modules are defining today for use in their init functions. Was discussed on Python-Dev and was well-received there. Andrew, I dislike the name PyModule_AddConstantLong, because that Python ints *happen* to be C longs should be an implementation detail. Since the function is actually adding a Python int, I'm afraid I like PyModule_AddConstantInt better. Oh, yuck. Ah! PyModule_AddConstantPyInt. ------------------------------------------------------- Date: 2000-Aug-21 17:46 By: gvanrossum Comment: I like the idea fine, but don't think it's important enough to rush it into 2.0. Anyway it needs docs for api.tex. AddConstantPyInt is a bad name becase "PyInt" suggests that the argument is a Python int object, not a C int. Suggestion: PyModule_AddIntConstant and PyModule_AddStringConstant. I'm a bit worried by the implied DECREF in PyModule_AddObject -- this should better go into the other two, or the name should be changed, maybe to _AddNewObject. ------------------------------------------------------- Date: 2000-Sep-15 09:41 By: gvanrossum Comment: Andrew, this was revived. Can you address the comments? I'm not against adding this to 2.0b2, although there are undoubtedly more important things to do. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101233&group_id=5470 From noreply@sourceforge.net Fri Sep 15 17:51:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 09:51:33 -0700 Subject: [Patches] [Patch #101388] Backward compatibility hook Message-ID: <200009151651.JAA29835@bush.i.sourceforge.net> Patch #101388 has been updated. Project: Category: documentation Status: Open Summary: Backward compatibility hook Follow-Ups: Date: 2000-Sep-01 07:41 By: jhylton Comment: same deal: postponed for now, but may be considered post 2.0b1 ------------------------------------------------------- Date: 2000-Sep-15 07:17 By: fdrake Comment: The test using sys.hexversion may be more readable if sys.version_info is used instead: if sys.version_info < (2, 0): ... ------------------------------------------------------- Date: 2000-Sep-15 09:51 By: gvanrossum Comment: This is a doc update. But I believe that it's backwards. The proper solution is to let __getslice__(self, lo, hi) call self.__getitem__(slice(lo, hi)) -- or self[lo:hi:]; and similar for the others. Then you can write code in __getitem__ that handles slice objects (and tuples of slice objects). Why does he use max(i,0) etc.? I don't think that's needed or correct! The version check could be done to make it a bit faster. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101388&group_id=5470 From noreply@sourceforge.net Fri Sep 15 18:03:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 10:03:41 -0700 Subject: [Patches] [Patch #101390] Add special names to operator module as expected by user Message-ID: <200009151703.KAA30224@bush.i.sourceforge.net> Patch #101390 has been updated. Project: Category: library Status: Open Summary: Add special names to operator module as expected by user Follow-Ups: Date: 2000-Sep-01 07:42 By: jhylton Comment: third one: postponed for now ------------------------------------------------------- Date: 2000-Sep-15 10:03 By: gvanrossum Comment: This does several things. It adds and documents __contains__, and it adds and documents __invert__ as an alias for __inv__. I agree with the goal, but the implementation is imperfect. E.g. it defines inv, __inv__, and __invert__, but not invert. I think that instead of defining a new macro spam3() and using it twice, it can use two calls to spam2() for inv and invert, and something similar for contains and sequenceIncludes (the latter should be deprecated, BTW). Fred, can you sort this mess out? I'd be happy to review the changes before you check them in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101390&group_id=5470 From noreply@sourceforge.net Fri Sep 15 18:12:26 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 10:12:26 -0700 Subject: [Patches] [Patch #101437] Fix for 110675: GNU pth support Message-ID: <200009151712.KAA30559@bush.i.sourceforge.net> Patch #101437 has been updated. Project: Category: core (C code) Status: Open Summary: Fix for 110675: GNU pth support Follow-Ups: Date: 2000-Sep-06 17:01 By: adustman Comment: Makes better use of GNU autoconf. configure --with-pth[=DIR] # --with-threads implied Passes test_fork1 and test_thread. Tested with pth-1.3.7. XXX With pth, select() (and others) do not wake up in response to signals. Example: >>> import time >>> time.sleep(10) [hit ctrl-C, no response for 10 seconds] Traceback (most recent call last): File "", line 1, in ? KeyboardInterrupt >>> I have a patch to pth that fixes this that I will try to get incorporated. ------------------------------------------------------- Date: 2000-Sep-15 10:12 By: gvanrossum Comment: Andy, There's one form issue: you shouldn't patch config.h.in, you should patch acconfig.h. And you should make sure that HAVE_PTH is properly in the alphabet between HAVE_LONG_LONG and HAVE_UINTPTR_T. Otherwise I don't have an objection. If I don't hear from you soon I may check it in myself. But since I can't test it I prefer to hear it from you! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101437&group_id=5470 From noreply@sourceforge.net Fri Sep 15 18:18:51 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 10:18:51 -0700 Subject: [Patches] [Patch #101534] Use confirmations rather than assertions Message-ID: <200009151718.KAA16063@delerium.i.sourceforge.net> Patch #101534 has been updated. Project: Category: XML Status: Open Summary: Use confirmations rather than assertions ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101534&group_id=5470 From noreply@sourceforge.net Fri Sep 15 18:19:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 10:19:40 -0700 Subject: [Patches] [Patch #101517] Fix for Bug 114333 (only reported bug in minidom) Message-ID: <200009151719.KAA16083@delerium.i.sourceforge.net> Patch #101517 has been updated. Project: Category: XML Status: Closed Summary: Fix for Bug 114333 (only reported bug in minidom) Follow-Ups: Date: 2000-Sep-15 06:58 By: fdrake Comment: Looks good, check it in. You should go through the code and transform "func( a, b )" to "func(a, b)", and "x=foo..." to "x = foo..." to conform to the Python style guide (http://www.python.org/doc/essys/styleguide.html). This should be a separate checkin. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101517&group_id=5470 From noreply@sourceforge.net Fri Sep 15 18:19:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 10:19:01 -0700 Subject: [Patches] [Patch #101534] Use confirmations rather than assertions Message-ID: <200009151719.KAA16072@delerium.i.sourceforge.net> Patch #101534 has been updated. Project: Category: XML Status: Open Summary: Use confirmations rather than assertions ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101534&group_id=5470 From noreply@sourceforge.net Fri Sep 15 18:40:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 10:40:32 -0700 Subject: [Patches] [Patch #101536] httplib should not close socket on zero-length response Message-ID: <200009151740.KAA31657@bush.i.sourceforge.net> Patch #101536 has been updated. Project: Category: library Status: Open Summary: httplib should not close socket on zero-length response ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101536&group_id=5470 From noreply@sourceforge.net Fri Sep 15 18:45:26 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 10:45:26 -0700 Subject: [Patches] [Patch #101536] httplib should not close socket on zero-length response Message-ID: <200009151745.KAA31858@bush.i.sourceforge.net> Patch #101536 has been updated. Project: Category: library Status: Open Summary: httplib should not close socket on zero-length response Follow-Ups: Date: 2000-Sep-15 10:45 By: jhylton Comment: In the current httplib, an HTTPConnection object calls close on itself when it receives a response with a content-length == 0. I don't think this is a good feature and it is not backwards compatible with the old httplib, which left the socket open. We have had problems with clients of httplib that expect to always read whatever message body is returned. Reading from a socket with no data returns '' (and len('') == 0) which seems completely correct. This patch restores the old behavior and lets clients like urllib call read for any valid response. This patch also restores the set_debuglevel feature. I don't care much if this is included or not, but it added to debug the other problem and it was helpful for that. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101536&group_id=5470 From noreply@sourceforge.net Fri Sep 15 18:52:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 10:52:17 -0700 Subject: [Patches] [Patch #101537] Include/ceval.h mentions obsolete RET_SAVE macro Message-ID: <200009151752.KAA17382@delerium.i.sourceforge.net> Patch #101537 has been updated. Project: Category: core (C code) Status: Open Summary: Include/ceval.h mentions obsolete RET_SAVE macro ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101537&group_id=5470 From noreply@sourceforge.net Fri Sep 15 19:02:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 11:02:05 -0700 Subject: [Patches] [Patch #101529] urllib and redirects Message-ID: <200009151802.LAA17781@delerium.i.sourceforge.net> Patch #101529 has been updated. Project: Category: library Status: Rejected Summary: urllib and redirects Follow-Ups: Date: 2000-Sep-15 06:28 By: htrd Comment: httplib is sometimes closing its file earlier than before. This confuses urllib, which expects to have to close the file itself. This patch fixes the behaviour in urllib, although I am not sure that the real bug isnt the change in httplib. ------------------------------------------------------- Date: 2000-Sep-15 06:32 By: jhylton Comment: Ah, serendipity. I'm debugging the same problem right now! ------------------------------------------------------- Date: 2000-Sep-15 06:42 By: gvanrossum Comment: Of course this should be fixed in httplib. ------------------------------------------------------- Date: 2000-Sep-15 11:02 By: jhylton Comment: patch #101536 fixes the source of this problem ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101529&group_id=5470 From noreply@sourceforge.net Fri Sep 15 19:08:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 11:08:41 -0700 Subject: [Patches] [Patch #101537] Include/ceval.h mentions obsolete RET_SAVE macro Message-ID: <200009151808.LAA18035@delerium.i.sourceforge.net> Patch #101537 has been updated. Project: Category: core (C code) Status: Accepted Summary: Include/ceval.h mentions obsolete RET_SAVE macro ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101537&group_id=5470 From noreply@sourceforge.net Fri Sep 15 19:18:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 11:18:24 -0700 Subject: [Patches] [Patch #101394] lookdict optimizations Message-ID: <200009151818.LAA18462@delerium.i.sourceforge.net> Patch #101394 has been updated. Project: Category: core (C code) Status: Accepted Summary: lookdict optimizations Follow-Ups: Date: 2000-Sep-03 21:09 By: marangoz Comment: Let's add a comment, although this has been raised on python-dev. This patch proposes a couple of ideas for optimizing & speeding dict lookups -- not all of them need to be applied though. - clear the eventual errors from Object_Compare only on need (this logic needs to be double-checked once again to see whether it really works) - defer variable initializations after the most common return cases - specialize string_compare() for lookdict_string. The test comparing the first char, before calling memcmp(), can be added too. - inline the first item probe in PyDict_GetItem. This saves a func call for the most common case (common to lookdict & lookdict_string). ------------------------------------------------------- Date: 2000-Sep-04 06:45 By: gvanrossum Comment: Quick comments: we should *always* call PyErr_Occurred() after PyObject_Compare() (and PyErr_Clear() if PyErr_Occurred() returned true). PyErr_Compare() really doesn't expect a pending exception coming in and so *not* clearing the error might break the *next* PyErr_Compare() call. (This doesn't happen typically but PyObject_Compare() can execute arbitrary code, some of which might call PyErr_Occurred() without calling PyErr_Clear() first.) ------------------------------------------------------- Date: 2000-Sep-05 06:05 By: none Comment: Correct! But then, aren't the current "else" if(cmp == 0) clauses risky after PyObject_Compare()? An exception may be set in external code while making Object_Compare() to return 0! Perhaps not in Python source, but in buggy extensions. lookdict() will then overlook this "hit". Patch updated, without "else" clauses and with the 1st char check in string_compare_equal(). ------------------------------------------------------- Date: 2000-Sep-05 06:08 By: marangoz Comment: Argh! These Web interfaces strike again - forgot to login. ------------------------------------------------------- Date: 2000-Sep-14 09:26 By: fdrake Comment: Revised patch: Instead of defining a function to do the fast string comparison, use a macro, but let it use the documented string object API (PyString_GET_SIZE(), PyString_AS_STRING()) instead of breaking the encapsulation in the code. This avoids all function calls to do the string compare, except memcmp() (which good compilers can inline anyway). Vladimir, take a look at this; if you're happy, I'm happy, and you can check it in. Thanks! ------------------------------------------------------- Date: 2000-Sep-14 13:51 By: fdrake Comment: Guido, please review (since Vladimir's away). ------------------------------------------------------- Date: 2000-Sep-15 11:18 By: gvanrossum Comment: Accepted. Assuming you've tested this, it looks fine to me. Can you time this a bit? There's one niggling issue: some people think that before you do memcmp() you should manually compare the first character. Others think that's unnecessary (since a good compiler can inline memcmp anyway). (It's also a bit scary if the size is zero.) So please ignore this but keep it in mind for timing experiments. :) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101394&group_id=5470 From noreply@sourceforge.net Fri Sep 15 19:23:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 11:23:16 -0700 Subject: [Patches] [Patch #101531] Fix for GC bug #113812 Message-ID: <200009151823.LAA18626@delerium.i.sourceforge.net> Patch #101531 has been updated. Project: Category: core (C code) Status: Accepted Summary: Fix for GC bug #113812 Follow-Ups: Date: 2000-Sep-15 11:23 By: gvanrossum Comment: It's your code, Neil! Just check it in, and then mark the patch as closed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101531&group_id=5470 From noreply@sourceforge.net Fri Sep 15 19:24:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 11:24:38 -0700 Subject: [Patches] [Patch #101496] Support switches -h and -V (help & version) Message-ID: <200009151824.LAA18675@delerium.i.sourceforge.net> Patch #101496 has been updated. Project: Category: core (C code) Status: Accepted Summary: Support switches -h and -V (help & version) Follow-Ups: Date: 2000-Sep-14 07:18 By: fdrake Comment: This looks good to me; fix Misc/python.man as well, then check it in. ------------------------------------------------------- Date: 2000-Sep-14 22:03 By: bwarsaw Comment: Jeremy, please rule: can this go into 2.0beta2? If so, reassign back to me and I'll check it in. ------------------------------------------------------- Date: 2000-Sep-15 04:52 By: gvanrossum Comment: Why does -h print the usage and then continue to function, while -V prints the version and exits? (Should it check that there are no other command line args before exiting???) Note that you also need to fix Misc/python.man ------------------------------------------------------- Date: 2000-Sep-15 07:31 By: bwarsaw Comment: Yes, -h exits too. usage() calls exit(). Here's an updated patch that includes mods to Misc/python.man ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101496&group_id=5470 From noreply@sourceforge.net Fri Sep 15 19:32:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 11:32:56 -0700 Subject: [Patches] [Patch #101512] Support parsing of already opened file objects Message-ID: <200009151832.LAA19005@delerium.i.sourceforge.net> Patch #101512 has been updated. Project: Category: XML Status: Open Summary: Support parsing of already opened file objects Follow-Ups: Date: 2000-Sep-14 11:15 By: jhylton Comment: I don't particularly care for this interface change. It appears that the parser will close the file if passed as an argument. Since the parser did not open the file, it should not close it. It seems to me that this feature should be a separate method. Also, there seem to be a lot of style problems with this code. There is inconsistent use of whitespace around ()s and =s. It should be consistent above all! And it should use the approved Python style. ------------------------------------------------------- Date: 2000-Sep-14 12:21 By: prescod Comment: This isn't an interface change, it just makes the interface work the way it says it does. If fixes a FIXME. A separate method is a good idea but it would have to be agreed upon by the xml-sig (or at least implemented by Lars, the main SAX maintainer). I see that as part of the larger refactoring that Lars is doing. I'm not clear what line of code closes the file. It looks to me like it just goes out of scope still open. ------------------------------------------------------- Date: 2000-Sep-14 14:08 By: fdrake Comment: I'm hesitant to approve this myself; I don't like the overloading. (Though I agree that this simply brings the implementation into line with the documentation, such as it is.) The Java equivelent uses an overloaded parse() method, but Java provides direct support for this in the language definition. I think the Python SAX2 definition should provide separate methods. Let's wait for Lars to weigh in on the API issues. ------------------------------------------------------- Date: 2000-Sep-15 04:03 By: gvanrossum Comment: I would approve this if it took care of Jeremy's concern: if the file is opened by the caller, the callee should not close it. Given that Java overloads parse(), the Python approach of testing for a file is fine; I don't think it's necessary to dd a new method. ------------------------------------------------------- Date: 2000-Sep-15 06:53 By: prescod Comment: I believe Jeremy to be wrong. If you do a "grep" in the xml/sig directory you'll find that files are never closed. They just go out of scope. If we opened the file then it will close when it goes out of scope. If the caller opened the file, it will close when they throw away their last reference to it. The wonders of reference counting! ------------------------------------------------------- Date: 2000-Sep-15 06:56 By: jhylton Comment: It sounds like the code has the opposite sort of bug, then. It opens file and does not explicitly close them. The code should not depend on the reference counting mechanism to close files. ------------------------------------------------------- Date: 2000-Sep-15 07:29 By: prescod Comment: The word bug is too strong when all the module does is depend on documented Python features. Allowing auto-closing of files is one of the major arguments for Python's reference counting (according to the Python FAQ) and an advantage of Python over Java et al. If you do explicit closing you reintroduce the same lifetime issues that make pointer handling such a hassle in C++. In this particular case, the lifetime of the file object is pretty easy to track (barring funny stuff) so adding a close would be relatively easy and would make portability to JPython easier. I would like to hear what the BeOpen concensus is so that I can add it to my personal style guide. ------------------------------------------------------- Date: 2000-Sep-15 07:52 By: gvanrossum Comment: BeOpen doesn't enter into it. :-) PythonLabs is what counts. Consensus is had has been as Jeremy says: iff you open a file, you should close it. Note: adding close() should be a separate patch. Fred: you can accept this one once the close() patch is in. ------------------------------------------------------- Date: 2000-Sep-15 11:32 By: prescod Comment: The features are intertwined. The best implementation strategy requires a local rewrite of the method. Therefore the previous patch becomes redundant and unhelpful. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101512&group_id=5470 From noreply@sourceforge.net Fri Sep 15 19:35:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 11:35:49 -0700 Subject: [Patches] [Patch #101514] Remove references to self._source Message-ID: <200009151835.LAA19144@delerium.i.sourceforge.net> Patch #101514 has been updated. Project: Category: XML Status: Open Summary: Remove references to self._source Follow-Ups: Date: 2000-Sep-14 12:37 By: prescod Comment: (this update to the patch makes fewer changes to the original code than the original patch based on the philosophy that it will be easier for Lars to apply his fixes if the code changes as little as possible) Read the comment about InputSource in the patch. All references to self._source are removed. Remove special case handling of streams versus strings (done in xmlreader now). ------------------------------------------------------- Date: 2000-Sep-14 13:49 By: fdrake Comment: Please don't comment out the lines; just remove them. CVS will keep the history of what happened just fine. Please make this mechanical change and check it in. ------------------------------------------------------- Date: 2000-Sep-14 21:37 By: fdrake Comment: Based on email from Paul, let's wait and let Lars say something about this one. Re-opened and assigned to Lars for review. ------------------------------------------------------- Date: 2000-Sep-15 11:35 By: prescod Comment: I'd rather not wait around. People want to check this stuff out and test. Can I change my mind and just delete the darn lines? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101514&group_id=5470 From noreply@sourceforge.net Fri Sep 15 19:40:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 11:40:46 -0700 Subject: [Patches] [Patch #101496] Support switches -h and -V (help & version) Message-ID: <200009151840.LAA01480@bush.i.sourceforge.net> Patch #101496 has been updated. Project: Category: core (C code) Status: Closed Summary: Support switches -h and -V (help & version) Follow-Ups: Date: 2000-Sep-14 07:18 By: fdrake Comment: This looks good to me; fix Misc/python.man as well, then check it in. ------------------------------------------------------- Date: 2000-Sep-14 22:03 By: bwarsaw Comment: Jeremy, please rule: can this go into 2.0beta2? If so, reassign back to me and I'll check it in. ------------------------------------------------------- Date: 2000-Sep-15 04:52 By: gvanrossum Comment: Why does -h print the usage and then continue to function, while -V prints the version and exits? (Should it check that there are no other command line args before exiting???) Note that you also need to fix Misc/python.man ------------------------------------------------------- Date: 2000-Sep-15 07:31 By: bwarsaw Comment: Yes, -h exits too. usage() calls exit(). Here's an updated patch that includes mods to Misc/python.man ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101496&group_id=5470 From noreply@sourceforge.net Fri Sep 15 19:41:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 11:41:37 -0700 Subject: [Patches] [Patch #101511] Fix typos Message-ID: <200009151841.LAA19342@delerium.i.sourceforge.net> Patch #101511 has been updated. Project: Category: XML Status: Closed Summary: Fix typos Follow-Ups: Date: 2000-Sep-14 13:46 By: fdrake Comment: Please check this in -- thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101511&group_id=5470 From noreply@sourceforge.net Fri Sep 15 19:42:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 11:42:21 -0700 Subject: [Patches] [Patch #101514] Remove references to self._source Message-ID: <200009151842.LAA19372@delerium.i.sourceforge.net> Patch #101514 has been updated. Project: Category: XML Status: Accepted Summary: Remove references to self._source Follow-Ups: Date: 2000-Sep-14 12:37 By: prescod Comment: (this update to the patch makes fewer changes to the original code than the original patch based on the philosophy that it will be easier for Lars to apply his fixes if the code changes as little as possible) Read the comment about InputSource in the patch. All references to self._source are removed. Remove special case handling of streams versus strings (done in xmlreader now). ------------------------------------------------------- Date: 2000-Sep-14 13:49 By: fdrake Comment: Please don't comment out the lines; just remove them. CVS will keep the history of what happened just fine. Please make this mechanical change and check it in. ------------------------------------------------------- Date: 2000-Sep-14 21:37 By: fdrake Comment: Based on email from Paul, let's wait and let Lars say something about this one. Re-opened and assigned to Lars for review. ------------------------------------------------------- Date: 2000-Sep-15 11:35 By: prescod Comment: I'd rather not wait around. People want to check this stuff out and test. Can I change my mind and just delete the darn lines? ------------------------------------------------------- Date: 2000-Sep-15 11:42 By: fdrake Comment: Check it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101514&group_id=5470 From noreply@sourceforge.net Fri Sep 15 19:45:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 11:45:44 -0700 Subject: [Patches] [Patch #101534] Use confirmations rather than assertions Message-ID: <200009151845.LAA19518@delerium.i.sourceforge.net> Patch #101534 has been updated. Project: Category: XML Status: Accepted Summary: Use confirmations rather than assertions Follow-Ups: Date: 2000-Sep-15 11:45 By: fdrake Comment: Check it in. Please convert this script to conform to the Python style guide as a second checkin. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101534&group_id=5470 From noreply@sourceforge.net Fri Sep 15 21:25:20 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 13:25:20 -0700 Subject: [Patches] [Patch #101437] Fix for 110675: GNU pth support Message-ID: <200009152025.NAA23133@delerium.i.sourceforge.net> Patch #101437 has been updated. Project: Category: core (C code) Status: Open Summary: Fix for 110675: GNU pth support Follow-Ups: Date: 2000-Sep-06 17:01 By: adustman Comment: Makes better use of GNU autoconf. configure --with-pth[=DIR] # --with-threads implied Passes test_fork1 and test_thread. Tested with pth-1.3.7. XXX With pth, select() (and others) do not wake up in response to signals. Example: >>> import time >>> time.sleep(10) [hit ctrl-C, no response for 10 seconds] Traceback (most recent call last): File "", line 1, in ? KeyboardInterrupt >>> I have a patch to pth that fixes this that I will try to get incorporated. ------------------------------------------------------- Date: 2000-Sep-15 10:12 By: gvanrossum Comment: Andy, There's one form issue: you shouldn't patch config.h.in, you should patch acconfig.h. And you should make sure that HAVE_PTH is properly in the alphabet between HAVE_LONG_LONG and HAVE_UINTPTR_T. Otherwise I don't have an objection. If I don't hear from you soon I may check it in myself. But since I can't test it I prefer to hear it from you! ------------------------------------------------------- Date: 2000-Sep-15 13:25 By: adustman Comment: This patch should fix the style problems. However, I have noticed a new problem: test_poll dumps core: **Pth** SCHEDULER INTERNAL ERROR: no more thread(s) available to schedule!?!? I suspect this is purely a pth error. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101437&group_id=5470 From noreply@sourceforge.net Fri Sep 15 21:51:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 13:51:17 -0700 Subject: [Patches] [Patch #101437] Fix for 110675: GNU pth support Message-ID: <200009152051.NAA24195@delerium.i.sourceforge.net> Patch #101437 has been updated. Project: Category: core (C code) Status: Open Summary: Fix for 110675: GNU pth support Follow-Ups: Date: 2000-Sep-06 17:01 By: adustman Comment: Makes better use of GNU autoconf. configure --with-pth[=DIR] # --with-threads implied Passes test_fork1 and test_thread. Tested with pth-1.3.7. XXX With pth, select() (and others) do not wake up in response to signals. Example: >>> import time >>> time.sleep(10) [hit ctrl-C, no response for 10 seconds] Traceback (most recent call last): File "", line 1, in ? KeyboardInterrupt >>> I have a patch to pth that fixes this that I will try to get incorporated. ------------------------------------------------------- Date: 2000-Sep-15 10:12 By: gvanrossum Comment: Andy, There's one form issue: you shouldn't patch config.h.in, you should patch acconfig.h. And you should make sure that HAVE_PTH is properly in the alphabet between HAVE_LONG_LONG and HAVE_UINTPTR_T. Otherwise I don't have an objection. If I don't hear from you soon I may check it in myself. But since I can't test it I prefer to hear it from you! ------------------------------------------------------- Date: 2000-Sep-15 13:25 By: adustman Comment: This patch should fix the style problems. However, I have noticed a new problem: test_poll dumps core: **Pth** SCHEDULER INTERNAL ERROR: no more thread(s) available to schedule!?!? I suspect this is purely a pth error. ------------------------------------------------------- Date: 2000-Sep-15 13:51 By: adustman Comment: Note: Support for poll() (in selectmodule) did not exist at the time I came up with the original pth support. However, I neglected to test test_poll when submitting the original version of this patch. Error occurs with both pth-1.3.7 and 1.4a2. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101437&group_id=5470 From noreply@sourceforge.net Sat Sep 16 01:30:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Sep 2000 17:30:17 -0700 Subject: [Patches] [Patch #101437] Fix for 110675: GNU pth support Message-ID: <200009160030.RAA16174@bush.i.sourceforge.net> Patch #101437 has been updated. Project: Category: core (C code) Status: Open Summary: Fix for 110675: GNU pth support Follow-Ups: Date: 2000-Sep-06 17:01 By: adustman Comment: Makes better use of GNU autoconf. configure --with-pth[=DIR] # --with-threads implied Passes test_fork1 and test_thread. Tested with pth-1.3.7. XXX With pth, select() (and others) do not wake up in response to signals. Example: >>> import time >>> time.sleep(10) [hit ctrl-C, no response for 10 seconds] Traceback (most recent call last): File "", line 1, in ? KeyboardInterrupt >>> I have a patch to pth that fixes this that I will try to get incorporated. ------------------------------------------------------- Date: 2000-Sep-15 10:12 By: gvanrossum Comment: Andy, There's one form issue: you shouldn't patch config.h.in, you should patch acconfig.h. And you should make sure that HAVE_PTH is properly in the alphabet between HAVE_LONG_LONG and HAVE_UINTPTR_T. Otherwise I don't have an objection. If I don't hear from you soon I may check it in myself. But since I can't test it I prefer to hear it from you! ------------------------------------------------------- Date: 2000-Sep-15 13:25 By: adustman Comment: This patch should fix the style problems. However, I have noticed a new problem: test_poll dumps core: **Pth** SCHEDULER INTERNAL ERROR: no more thread(s) available to schedule!?!? I suspect this is purely a pth error. ------------------------------------------------------- Date: 2000-Sep-15 13:51 By: adustman Comment: Note: Support for poll() (in selectmodule) did not exist at the time I came up with the original pth support. However, I neglected to test test_poll when submitting the original version of this patch. Error occurs with both pth-1.3.7 and 1.4a2. ------------------------------------------------------- Date: 2000-Sep-15 17:30 By: gvanrossum Comment: I get autoconf errors with this. I think the AC_CHeCK_PTH macro is undefined. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101437&group_id=5470 From noreply@sourceforge.net Sat Sep 16 11:34:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Sep 2000 03:34:04 -0700 Subject: [Patches] [Patch #101514] Remove references to self._source Message-ID: <200009161034.DAA18847@delerium.i.sourceforge.net> Patch #101514 has been updated. Project: Category: XML Status: Accepted Summary: Remove references to self._source Follow-Ups: Date: 2000-Sep-14 12:37 By: prescod Comment: (this update to the patch makes fewer changes to the original code than the original patch based on the philosophy that it will be easier for Lars to apply his fixes if the code changes as little as possible) Read the comment about InputSource in the patch. All references to self._source are removed. Remove special case handling of streams versus strings (done in xmlreader now). ------------------------------------------------------- Date: 2000-Sep-14 13:49 By: fdrake Comment: Please don't comment out the lines; just remove them. CVS will keep the history of what happened just fine. Please make this mechanical change and check it in. ------------------------------------------------------- Date: 2000-Sep-14 21:37 By: fdrake Comment: Based on email from Paul, let's wait and let Lars say something about this one. Re-opened and assigned to Lars for review. ------------------------------------------------------- Date: 2000-Sep-15 11:35 By: prescod Comment: I'd rather not wait around. People want to check this stuff out and test. Can I change my mind and just delete the darn lines? ------------------------------------------------------- Date: 2000-Sep-15 11:42 By: fdrake Comment: Check it in. ------------------------------------------------------- Date: 2000-Sep-16 03:34 By: larsga Comment: Basically, my stance is that we need InputSource and so I think this patch should be rejected.In order for the EntityResolver to do its job properly (and also to simplify the XMLReader interface) the InputSource class is needed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101514&group_id=5470 From noreply@sourceforge.net Sat Sep 16 14:38:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Sep 2000 06:38:24 -0700 Subject: [Patches] [Patch #101514] Remove references to self._source Message-ID: <200009161338.GAA24915@delerium.i.sourceforge.net> Patch #101514 has been updated. Project: Category: XML Status: Open Summary: Remove references to self._source Follow-Ups: Date: 2000-Sep-14 12:37 By: prescod Comment: (this update to the patch makes fewer changes to the original code than the original patch based on the philosophy that it will be easier for Lars to apply his fixes if the code changes as little as possible) Read the comment about InputSource in the patch. All references to self._source are removed. Remove special case handling of streams versus strings (done in xmlreader now). ------------------------------------------------------- Date: 2000-Sep-14 13:49 By: fdrake Comment: Please don't comment out the lines; just remove them. CVS will keep the history of what happened just fine. Please make this mechanical change and check it in. ------------------------------------------------------- Date: 2000-Sep-14 21:37 By: fdrake Comment: Based on email from Paul, let's wait and let Lars say something about this one. Re-opened and assigned to Lars for review. ------------------------------------------------------- Date: 2000-Sep-15 11:35 By: prescod Comment: I'd rather not wait around. People want to check this stuff out and test. Can I change my mind and just delete the darn lines? ------------------------------------------------------- Date: 2000-Sep-15 11:42 By: fdrake Comment: Check it in. ------------------------------------------------------- Date: 2000-Sep-16 03:34 By: larsga Comment: Basically, my stance is that we need InputSource and so I think this patch should be rejected.In order for the EntityResolver to do its job properly (and also to simplify the XMLReader interface) the InputSource class is needed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101514&group_id=5470 From noreply@sourceforge.net Sat Sep 16 15:07:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Sep 2000 07:07:16 -0700 Subject: [Patches] [Patch #101514] Remove references to self._source Message-ID: <200009161407.HAA25832@delerium.i.sourceforge.net> Patch #101514 has been updated. Project: Category: XML Status: Rejected Summary: Remove references to self._source Follow-Ups: Date: 2000-Sep-14 12:37 By: prescod Comment: (this update to the patch makes fewer changes to the original code than the original patch based on the philosophy that it will be easier for Lars to apply his fixes if the code changes as little as possible) Read the comment about InputSource in the patch. All references to self._source are removed. Remove special case handling of streams versus strings (done in xmlreader now). ------------------------------------------------------- Date: 2000-Sep-14 13:49 By: fdrake Comment: Please don't comment out the lines; just remove them. CVS will keep the history of what happened just fine. Please make this mechanical change and check it in. ------------------------------------------------------- Date: 2000-Sep-14 21:37 By: fdrake Comment: Based on email from Paul, let's wait and let Lars say something about this one. Re-opened and assigned to Lars for review. ------------------------------------------------------- Date: 2000-Sep-15 11:35 By: prescod Comment: I'd rather not wait around. People want to check this stuff out and test. Can I change my mind and just delete the darn lines? ------------------------------------------------------- Date: 2000-Sep-15 11:42 By: fdrake Comment: Check it in. ------------------------------------------------------- Date: 2000-Sep-16 03:34 By: larsga Comment: Basically, my stance is that we need InputSource and so I think this patch should be rejected.In order for the EntityResolver to do its job properly (and also to simplify the XMLReader interface) the InputSource class is needed. ------------------------------------------------------- Date: 2000-Sep-16 07:07 By: fdrake Comment: Lars said reject it, so it's out! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101514&group_id=5470 From noreply@sourceforge.net Sat Sep 16 15:09:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Sep 2000 07:09:19 -0700 Subject: [Patches] [Patch #101437] Fix for 110675: GNU pth support Message-ID: <200009161409.HAA09783@bush.i.sourceforge.net> Patch #101437 has been updated. Project: Category: core (C code) Status: Open Summary: Fix for 110675: GNU pth support Follow-Ups: Date: 2000-Sep-06 17:01 By: adustman Comment: Makes better use of GNU autoconf. configure --with-pth[=DIR] # --with-threads implied Passes test_fork1 and test_thread. Tested with pth-1.3.7. XXX With pth, select() (and others) do not wake up in response to signals. Example: >>> import time >>> time.sleep(10) [hit ctrl-C, no response for 10 seconds] Traceback (most recent call last): File "", line 1, in ? KeyboardInterrupt >>> I have a patch to pth that fixes this that I will try to get incorporated. ------------------------------------------------------- Date: 2000-Sep-15 10:12 By: gvanrossum Comment: Andy, There's one form issue: you shouldn't patch config.h.in, you should patch acconfig.h. And you should make sure that HAVE_PTH is properly in the alphabet between HAVE_LONG_LONG and HAVE_UINTPTR_T. Otherwise I don't have an objection. If I don't hear from you soon I may check it in myself. But since I can't test it I prefer to hear it from you! ------------------------------------------------------- Date: 2000-Sep-15 13:25 By: adustman Comment: This patch should fix the style problems. However, I have noticed a new problem: test_poll dumps core: **Pth** SCHEDULER INTERNAL ERROR: no more thread(s) available to schedule!?!? I suspect this is purely a pth error. ------------------------------------------------------- Date: 2000-Sep-15 13:51 By: adustman Comment: Note: Support for poll() (in selectmodule) did not exist at the time I came up with the original pth support. However, I neglected to test test_poll when submitting the original version of this patch. Error occurs with both pth-1.3.7 and 1.4a2. ------------------------------------------------------- Date: 2000-Sep-15 17:30 By: gvanrossum Comment: I get autoconf errors with this. I think the AC_CHeCK_PTH macro is undefined. ------------------------------------------------------- Date: 2000-Sep-16 07:09 By: gvanrossum Comment: I figured it out: Andy's patch to configure.in requires autoconf to be extended with a macro file that's part of Pth, pth.m4. I'm not comfortable with that. I've asked Andy for a patch that doesn't use AC_CHECK_PTH. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101437&group_id=5470 From noreply@sourceforge.net Sun Sep 17 00:14:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Sep 2000 16:14:31 -0700 Subject: [Patches] [Patch #100927] Fix for broken gethostbyname("0") Message-ID: <200009162314.QAA28869@bush.i.sourceforge.net> Patch #100927 has been updated. Project: Category: Modules Status: Open Summary: Fix for broken gethostbyname("0") Follow-Ups: Date: 2000-Jul-19 01:46 By: effbot Comment: why should this work? why is "gethostbyname" broken if it doesn't support "0" and "-1"? if it's important to support these values, shouldn't they be passed to the function as integers, not as strings? etc. (sorry, I'm usually able to make some kind of sense out of patches, but this one was a bit too cryptic ;-) ------------------------------------------------------- Date: 2000-Jul-20 23:13 By: ppessi Comment: It is not important to support "-1". "0" is INADDR_ANY in dot notation - same as "0.0.0.0" or "0.0.0" or "0.0". gethostbyname() should understand dot notation as well as domain names. For some reason, Windows gethostbyname() does not support "0" (obviously I'm a lazy typer, since I have not noticed that it does not support 0.0 nor 0.0.0 nor 0.0.0.0) unlike Unix platforms. I'll supply another patch ACN. ------------------------------------------------------- Date: 2000-Aug-13 19:49 By: nowonder Comment: As linux supports "0" (as well as "0.0" and friends), this would be nice to reduce platform dependency. But "00" is just as valid (not sure what Windows does with it), so to check this I think a bit more work has to be done. ------------------------------------------------------- Date: 2000-Aug-15 10:50 By: tim_one Comment: Changed status from Open to Postponed. There's been no action on this patch despite comments. If you want it to go into 2.0, address the concerns on Python-Dev Real Quick, and if so I'll Open it again. ------------------------------------------------------- Date: 2000-Sep-16 16:14 By: tim_one Comment: Assigned to Guido because he doubtless knows infinitely more about this than I do (Guido, if you know *anything* this, that's literally true ). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100927&group_id=5470 From noreply@sourceforge.net Sun Sep 17 00:18:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Sep 2000 16:18:29 -0700 Subject: [Patches] [Patch #101482] fix for Bug #114245 Message-ID: <200009162318.QAA29024@bush.i.sourceforge.net> Patch #101482 has been updated. Project: Category: core (C code) Status: Open Summary: fix for Bug #114245 Follow-Ups: Date: 2000-Sep-16 16:18 By: tim_one Comment: Mark, does this look reasonable to you? The thrust is to make utime work for directories under Win32 (as well as for files). THere's also an entry for this one in PEP 42 (Feature Requests). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101482&group_id=5470 From noreply@sourceforge.net Sun Sep 17 00:31:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Sep 2000 16:31:23 -0700 Subject: [Patches] [Patch #101482] fix for Bug #114245 Message-ID: <200009162331.QAA29383@bush.i.sourceforge.net> Patch #101482 has been updated. Project: Category: core (C code) Status: Open Summary: fix for Bug #114245 Follow-Ups: Date: 2000-Sep-16 16:18 By: tim_one Comment: Mark, does this look reasonable to you? The thrust is to make utime work for directories under Win32 (as well as for files). THere's also an entry for this one in PEP 42 (Feature Requests). ------------------------------------------------------- Date: 2000-Sep-16 16:31 By: mhammond Comment: With a quick look and no decent analysis, I can't see a good reason why this wouldnt work. However, see http://support.microsoft.com/support/kb/articles/q167/2/96.asp for the official way of doing this - it is significantly different. I have the above KB code all Python-ready, as it was used in the Windows CE port. I am happy to send this to anyone and everyone, but I am afraid I don't have time to rework the patch. Also note that I would _love_ to see whatever conversion routine you add made public in the DLL (and hence named appropriately). Windows CE could use it, as could the Python Win32 extensions - keep the bloat size down by keeping it in Python, and the cost of making it public isnt too bad! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101482&group_id=5470 From noreply@sourceforge.net Sun Sep 17 00:40:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Sep 2000 16:40:04 -0700 Subject: [Patches] [Patch #101544] Fix for 110609: Allow large long integers in formatting Message-ID: <200009162340.QAA13937@delerium.i.sourceforge.net> Patch #101544 has been updated. Project: Category: core (C code) Status: Open Summary: Fix for 110609: Allow large long integers in formatting ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101544&group_id=5470 From noreply@sourceforge.net Sun Sep 17 03:40:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Sep 2000 19:40:55 -0700 Subject: [Patches] [Patch #101482] fix for Bug #114245 Message-ID: <200009170240.TAA19722@delerium.i.sourceforge.net> Patch #101482 has been updated. Project: Category: core (C code) Status: Open Summary: fix for Bug #114245 Follow-Ups: Date: 2000-Sep-16 16:18 By: tim_one Comment: Mark, does this look reasonable to you? The thrust is to make utime work for directories under Win32 (as well as for files). THere's also an entry for this one in PEP 42 (Feature Requests). ------------------------------------------------------- Date: 2000-Sep-16 16:31 By: mhammond Comment: With a quick look and no decent analysis, I can't see a good reason why this wouldnt work. However, see http://support.microsoft.com/support/kb/articles/q167/2/96.asp for the official way of doing this - it is significantly different. I have the above KB code all Python-ready, as it was used in the Windows CE port. I am happy to send this to anyone and everyone, but I am afraid I don't have time to rework the patch. Also note that I would _love_ to see whatever conversion routine you add made public in the DLL (and hence named appropriately). Windows CE could use it, as could the Python Win32 extensions - keep the bloat size down by keeping it in Python, and the cost of making it public isnt too bad! ------------------------------------------------------- Date: 2000-Sep-16 19:40 By: none Comment: The time conversion function time2Time is modeled after MS C run time library code. It looks official way of doing this also ;). However UnixTimeToFileTime looks simpler. But I do not know if these two functions do the same thing. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101482&group_id=5470 From noreply@sourceforge.net Sun Sep 17 06:23:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Sep 2000 22:23:39 -0700 Subject: [Patches] [Patch #101390] Add special names to operator module as expected by user Message-ID: <200009170523.WAA24904@delerium.i.sourceforge.net> Patch #101390 has been updated. Project: Category: library Status: Open Summary: Add special names to operator module as expected by user Follow-Ups: Date: 2000-Sep-01 07:42 By: jhylton Comment: third one: postponed for now ------------------------------------------------------- Date: 2000-Sep-15 10:03 By: gvanrossum Comment: This does several things. It adds and documents __contains__, and it adds and documents __invert__ as an alias for __inv__. I agree with the goal, but the implementation is imperfect. E.g. it defines inv, __inv__, and __invert__, but not invert. I think that instead of defining a new macro spam3() and using it twice, it can use two calls to spam2() for inv and invert, and something similar for contains and sequenceIncludes (the latter should be deprecated, BTW). Fred, can you sort this mess out? I'd be happy to review the changes before you check them in. ------------------------------------------------------- Date: 2000-Sep-16 22:23 By: fdrake Comment: Revise patch to address Guido's concerns. Added :funcname to all calls to PyArg_ParseTuple(). Guido, please review. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101390&group_id=5470 From noreply@sourceforge.net Sun Sep 17 13:48:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 17 Sep 2000 05:48:10 -0700 Subject: [Patches] [Patch #101390] Add special names to operator module as expected by user Message-ID: <200009171248.FAA24493@bush.i.sourceforge.net> Patch #101390 has been updated. Project: Category: library Status: Accepted Summary: Add special names to operator module as expected by user Follow-Ups: Date: 2000-Sep-01 07:42 By: jhylton Comment: third one: postponed for now ------------------------------------------------------- Date: 2000-Sep-15 10:03 By: gvanrossum Comment: This does several things. It adds and documents __contains__, and it adds and documents __invert__ as an alias for __inv__. I agree with the goal, but the implementation is imperfect. E.g. it defines inv, __inv__, and __invert__, but not invert. I think that instead of defining a new macro spam3() and using it twice, it can use two calls to spam2() for inv and invert, and something similar for contains and sequenceIncludes (the latter should be deprecated, BTW). Fred, can you sort this mess out? I'd be happy to review the changes before you check them in. ------------------------------------------------------- Date: 2000-Sep-16 22:23 By: fdrake Comment: Revise patch to address Guido's concerns. Added :funcname to all calls to PyArg_ParseTuple(). Guido, please review. ------------------------------------------------------- Date: 2000-Sep-17 05:48 By: gvanrossum Comment: Accepted. Fred, go for it! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101390&group_id=5470 From noreply@sourceforge.net Sun Sep 17 17:11:20 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 17 Sep 2000 09:11:20 -0700 Subject: [Patches] [Patch #101390] Add special names to operator module as expected by user Message-ID: <200009171611.JAA15967@delerium.i.sourceforge.net> Patch #101390 has been updated. Project: Category: library Status: Closed Summary: Add special names to operator module as expected by user Follow-Ups: Date: 2000-Sep-01 07:42 By: jhylton Comment: third one: postponed for now ------------------------------------------------------- Date: 2000-Sep-15 10:03 By: gvanrossum Comment: This does several things. It adds and documents __contains__, and it adds and documents __invert__ as an alias for __inv__. I agree with the goal, but the implementation is imperfect. E.g. it defines inv, __inv__, and __invert__, but not invert. I think that instead of defining a new macro spam3() and using it twice, it can use two calls to spam2() for inv and invert, and something similar for contains and sequenceIncludes (the latter should be deprecated, BTW). Fred, can you sort this mess out? I'd be happy to review the changes before you check them in. ------------------------------------------------------- Date: 2000-Sep-16 22:23 By: fdrake Comment: Revise patch to address Guido's concerns. Added :funcname to all calls to PyArg_ParseTuple(). Guido, please review. ------------------------------------------------------- Date: 2000-Sep-17 05:48 By: gvanrossum Comment: Accepted. Fred, go for it! ------------------------------------------------------- Date: 2000-Sep-17 09:11 By: fdrake Comment: Checked in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101390&group_id=5470 From noreply@sourceforge.net Sun Sep 17 23:51:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 17 Sep 2000 15:51:47 -0700 Subject: [Patches] [Patch #101437] Fix for 110675: GNU pth support Message-ID: <200009172251.PAA30447@delerium.i.sourceforge.net> Patch #101437 has been updated. Project: Category: core (C code) Status: Open Summary: Fix for 110675: GNU pth support Follow-Ups: Date: 2000-Sep-06 17:01 By: adustman Comment: Makes better use of GNU autoconf. configure --with-pth[=DIR] # --with-threads implied Passes test_fork1 and test_thread. Tested with pth-1.3.7. XXX With pth, select() (and others) do not wake up in response to signals. Example: >>> import time >>> time.sleep(10) [hit ctrl-C, no response for 10 seconds] Traceback (most recent call last): File "", line 1, in ? KeyboardInterrupt >>> I have a patch to pth that fixes this that I will try to get incorporated. ------------------------------------------------------- Date: 2000-Sep-15 10:12 By: gvanrossum Comment: Andy, There's one form issue: you shouldn't patch config.h.in, you should patch acconfig.h. And you should make sure that HAVE_PTH is properly in the alphabet between HAVE_LONG_LONG and HAVE_UINTPTR_T. Otherwise I don't have an objection. If I don't hear from you soon I may check it in myself. But since I can't test it I prefer to hear it from you! ------------------------------------------------------- Date: 2000-Sep-15 13:25 By: adustman Comment: This patch should fix the style problems. However, I have noticed a new problem: test_poll dumps core: **Pth** SCHEDULER INTERNAL ERROR: no more thread(s) available to schedule!?!? I suspect this is purely a pth error. ------------------------------------------------------- Date: 2000-Sep-15 13:51 By: adustman Comment: Note: Support for poll() (in selectmodule) did not exist at the time I came up with the original pth support. However, I neglected to test test_poll when submitting the original version of this patch. Error occurs with both pth-1.3.7 and 1.4a2. ------------------------------------------------------- Date: 2000-Sep-15 17:30 By: gvanrossum Comment: I get autoconf errors with this. I think the AC_CHeCK_PTH macro is undefined. ------------------------------------------------------- Date: 2000-Sep-16 07:09 By: gvanrossum Comment: I figured it out: Andy's patch to configure.in requires autoconf to be extended with a macro file that's part of Pth, pth.m4. I'm not comfortable with that. I've asked Andy for a patch that doesn't use AC_CHECK_PTH. ------------------------------------------------------- Date: 2000-Sep-17 15:51 By: adustman Comment: This should meet your specifications. --with-pth is still required to use pth over POSIX threads. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101437&group_id=5470 From noreply@sourceforge.net Mon Sep 18 02:35:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 17 Sep 2000 18:35:32 -0700 Subject: [Patches] [Patch #101482] fix for Bug #114245 Message-ID: <200009180135.SAA19357@bush.i.sourceforge.net> Patch #101482 has been updated. Project: Category: core (C code) Status: Postponed Summary: fix for Bug #114245 Follow-Ups: Date: 2000-Sep-16 16:18 By: tim_one Comment: Mark, does this look reasonable to you? The thrust is to make utime work for directories under Win32 (as well as for files). THere's also an entry for this one in PEP 42 (Feature Requests). ------------------------------------------------------- Date: 2000-Sep-16 16:31 By: mhammond Comment: With a quick look and no decent analysis, I can't see a good reason why this wouldnt work. However, see http://support.microsoft.com/support/kb/articles/q167/2/96.asp for the official way of doing this - it is significantly different. I have the above KB code all Python-ready, as it was used in the Windows CE port. I am happy to send this to anyone and everyone, but I am afraid I don't have time to rework the patch. Also note that I would _love_ to see whatever conversion routine you add made public in the DLL (and hence named appropriately). Windows CE could use it, as could the Python Win32 extensions - keep the bloat size down by keeping it in Python, and the cost of making it public isnt too bad! ------------------------------------------------------- Date: 2000-Sep-16 19:40 By: none Comment: The time conversion function time2Time is modeled after MS C run time library code. It looks official way of doing this also ;). However UnixTimeToFileTime looks simpler. But I do not know if these two functions do the same thing. ------------------------------------------------------- Date: 2000-Sep-17 18:35 By: tim_one Comment: I changed this to Postponed: the scope is growing, and the bug this is related to was already changed to a Feature Request and added to PEP 42. Let's look at it again after 2.0final. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101482&group_id=5470 From noreply@sourceforge.net Mon Sep 18 02:38:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 17 Sep 2000 18:38:15 -0700 Subject: [Patches] [Patch #101391] Implemented UserList.__contains__ Message-ID: <200009180138.SAA19404@bush.i.sourceforge.net> Patch #101391 has been updated. Project: Category: Modules Status: Open Summary: Implemented UserList.__contains__ Follow-Ups: Date: 2000-Sep-01 07:42 By: jhylton Comment: you know the drill ------------------------------------------------------- Date: 2000-Sep-17 18:38 By: tim_one Comment: Reassigned to me in Moshe's absence. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101391&group_id=5470 From noreply@sourceforge.net Mon Sep 18 04:50:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 17 Sep 2000 20:50:02 -0700 Subject: [Patches] [Patch #101558] Fix for #112289 Message-ID: <200009180350.UAA23837@bush.i.sourceforge.net> Patch #101558 has been updated. Project: Category: Build Status: Open Summary: Fix for #112289 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101558&group_id=5470 From noreply@sourceforge.net Mon Sep 18 12:23:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Sep 2000 04:23:10 -0700 Subject: [Patches] [Patch #101388] Backward compatibility hook Message-ID: <200009181123.EAA23876@delerium.i.sourceforge.net> Patch #101388 has been updated. Project: Category: documentation Status: Open Summary: Backward compatibility hook Follow-Ups: Date: 2000-Sep-01 07:41 By: jhylton Comment: same deal: postponed for now, but may be considered post 2.0b1 ------------------------------------------------------- Date: 2000-Sep-15 07:17 By: fdrake Comment: The test using sys.hexversion may be more readable if sys.version_info is used instead: if sys.version_info < (2, 0): ... ------------------------------------------------------- Date: 2000-Sep-15 09:51 By: gvanrossum Comment: This is a doc update. But I believe that it's backwards. The proper solution is to let __getslice__(self, lo, hi) call self.__getitem__(slice(lo, hi)) -- or self[lo:hi:]; and similar for the others. Then you can write code in __getitem__ that handles slice objects (and tuples of slice objects). Why does he use max(i,0) etc.? I don't think that's needed or correct! The version check could be done to make it a bit faster. ------------------------------------------------------- Date: 2000-Sep-18 04:23 By: ods Comment: Why using max(i, 0) Let seq is the sequence with 5 items. Expression seq[-10:] is equivalent for seq.__getslice__(-5, sys.maxint) or seq.__getitem__(slice(-10, None, None)) but not seq.__getitem__(slice(-5, None, None))! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101388&group_id=5470 From noreply@sourceforge.net Mon Sep 18 15:22:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Sep 2000 07:22:57 -0700 Subject: [Patches] [Patch #101558] Fix for #112289 Message-ID: <200009181422.HAA13986@bush.i.sourceforge.net> Patch #101558 has been updated. Project: Category: Build Status: Open Summary: Fix for #112289 Follow-Ups: Date: 2000-Sep-18 07:22 By: gvanrossum Comment: Trent, if this looks okay to you, please check it in and close it. If you don't have time for this, say so and reassign it to someone in the PyLabs group. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101558&group_id=5470 From noreply@sourceforge.net Mon Sep 18 15:46:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Sep 2000 07:46:35 -0700 Subject: [Patches] [Patch #101388] Backward compatibility hook Message-ID: <200009181446.HAA14948@bush.i.sourceforge.net> Patch #101388 has been updated. Project: Category: documentation Status: Open Summary: Backward compatibility hook Follow-Ups: Date: 2000-Sep-01 07:41 By: jhylton Comment: same deal: postponed for now, but may be considered post 2.0b1 ------------------------------------------------------- Date: 2000-Sep-15 07:17 By: fdrake Comment: The test using sys.hexversion may be more readable if sys.version_info is used instead: if sys.version_info < (2, 0): ... ------------------------------------------------------- Date: 2000-Sep-15 09:51 By: gvanrossum Comment: This is a doc update. But I believe that it's backwards. The proper solution is to let __getslice__(self, lo, hi) call self.__getitem__(slice(lo, hi)) -- or self[lo:hi:]; and similar for the others. Then you can write code in __getitem__ that handles slice objects (and tuples of slice objects). Why does he use max(i,0) etc.? I don't think that's needed or correct! The version check could be done to make it a bit faster. ------------------------------------------------------- Date: 2000-Sep-18 04:23 By: ods Comment: Why using max(i, 0) Let seq is the sequence with 5 items. Expression seq[-10:] is equivalent for seq.__getslice__(-5, sys.maxint) or seq.__getitem__(slice(-10, None, None)) but not seq.__getitem__(slice(-5, None, None))! ------------------------------------------------------- Date: 2000-Sep-18 07:46 By: gvanrossum Comment: OK, I understand. Fred, if you want to do something with this, please use the version check you like and add a comment explaining the max() (if it's not already explained nearby). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101388&group_id=5470 From noreply@sourceforge.net Mon Sep 18 17:22:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Sep 2000 09:22:55 -0700 Subject: [Patches] [Patch #101458] Adding Unicode support to get|set|hasattr() Message-ID: <200009181622.JAA02769@delerium.i.sourceforge.net> Patch #101458 has been updated. Project: Category: core (C code) Status: Closed Summary: Adding Unicode support to get|set|hasattr() Follow-Ups: Date: 2000-Sep-08 14:48 By: lemburg Comment: This patch add Unicode support to the PyObject_SetAttr() and PyObject_GetAttr() APIs which are used by the mentioned builtin functions to set or query attributes. While implementing the patch I found that all current tp_getattro and tp_setattro implementations (classes, instances, methods) expect to find string objects as argument and don't even check for this. The patch realizes this behaviour by only accepting string or Unicode objects as name parameter to the two C APIs. ------------------------------------------------------- Date: 2000-Sep-14 15:08 By: gvanrossum Comment: Almost OK. You missed delattr()! Since that's a trivial fix, just check in the fixed patch and close the patch in SF. ------------------------------------------------------- Date: 2000-Sep-18 09:22 By: lemburg Comment: Added delattr() and checked in the patch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101458&group_id=5470 From noreply@sourceforge.net Mon Sep 18 17:28:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Sep 2000 09:28:43 -0700 Subject: [Patches] [Patch #101477] Fixes of ReadStream.readline() in UTF-16 and -LE codecs Message-ID: <200009181628.JAA02980@delerium.i.sourceforge.net> Patch #101477 has been updated. Project: Category: library Status: Open Summary: Fixes of ReadStream.readline() in UTF-16 and -LE codecs Follow-Ups: Date: 2000-Sep-14 07:09 By: fdrake Comment: Marc-Andre, please review this & decide what should happen next. ------------------------------------------------------- Date: 2000-Sep-18 09:28 By: lemburg Comment: I'm not sure whether this is the right fix: Unicode defines many more line break characters than just LF and the patch will only work correctly on Unix (also note that UTF-16 can be BE and LE -- your fix assumes LE). A true fix would have to also touch the .read() method and implement a true read-ahead buffer strategy to get this done right. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101477&group_id=5470 From noreply@sourceforge.net Mon Sep 18 17:34:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Sep 2000 09:34:44 -0700 Subject: [Patches] [Patch #101423] Fix for 110686: cStringIO.readlines Message-ID: <200009181634.JAA03213@delerium.i.sourceforge.net> Patch #101423 has been updated. Project: Category: library Status: Open Summary: Fix for 110686: cStringIO.readlines Follow-Ups: Date: 2000-Sep-18 09:34 By: lemburg Comment: The patch looks OK accept that you should replace the "0"s with NULL. Note that for full file object compatibility you will also have to provide a sizehint optional argument. BTW, where's the documentation part of the patch ?-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101423&group_id=5470 From noreply@sourceforge.net Mon Sep 18 17:46:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Sep 2000 09:46:38 -0700 Subject: [Patches] [Patch #101507] add 'punctuation' and 'printable' consts. to stropmodule.c Message-ID: <200009181646.JAA03671@delerium.i.sourceforge.net> Patch #101507 has been updated. Project: Category: core (C code) Status: Closed Summary: add 'punctuation' and 'printable' consts. to stropmodule.c Follow-Ups: Date: 2000-Sep-14 07:15 By: fdrake Comment: Why not just define these as constants in string.py? That would be more usable since strop is not necessarily available, and can be considered an implementation detail at best. Also, note that ispunct() and isprint() are available in the curses.ascii module. ------------------------------------------------------- Date: 2000-Sep-14 09:40 By: fdrake Comment: Response from Richard Mortier: Ah -- this was originally generated because I wanted to use it in Python 1.5.2 -- didn't realise later versions had curses.ascii Not defining them in string.py was because I wanted the behaviour of isprint() (in particular). ------------------------------------------------------- Date: 2000-Sep-14 09:43 By: fdrake Comment: My response to Richard: But why not just take the resulting value from your patch and add a couple of lines to Lib/string.py: printable = "..." punctuation = "..." If you can create an updated patch with this, and add a comment to the SourceForge interface explaining why these would be useful, we can consider it. ------------------------------------------------------- Date: 2000-Sep-15 02:17 By: rmm1002 Comment: --- string.py.old Sun Jul 16 13:04:30 2000 +++ string.py Fri Sep 15 10:06:58 2000 @@ -25,6 +25,8 @@ digits = '0123456789' hexdigits = digits + 'abcdef' + 'ABCDEF' octdigits = '01234567' +punctuaction = """!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~""" +printable = digits + letters + punctuation + whitespace # Case conversion helpers _idmap = '' ------------------------------------------------------- Date: 2000-Sep-15 02:27 By: rmm1002 Comment: now added to Lib/string.py instead of stropmodule.c; useful for a couple of scripts I was writing for checking output before printing it -- in general, given that the string module contains the constants "letters", "digits" et al, it seems natural that it should contain "punctuation" (and "printable" IMO, but given curses.ascii maybe not) ------------------------------------------------------- Date: 2000-Sep-18 09:46 By: fdrake Comment: Checked in as Lib/string.py revision 1.52. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101507&group_id=5470 From noreply@sourceforge.net Mon Sep 18 20:08:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Sep 2000 12:08:18 -0700 Subject: [Patches] [Patch #101534] Use confirmations rather than assertions Message-ID: <200009181908.MAA25431@bush.i.sourceforge.net> Patch #101534 has been updated. Project: Category: XML Status: Closed Summary: Use confirmations rather than assertions Follow-Ups: Date: 2000-Sep-15 11:45 By: fdrake Comment: Check it in. Please convert this script to conform to the Python style guide as a second checkin. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101534&group_id=5470 From noreply@sourceforge.net Mon Sep 18 20:25:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Sep 2000 12:25:56 -0700 Subject: [Patches] [Patch #101534] Use confirmations rather than assertions Message-ID: <200009181925.MAA10255@delerium.i.sourceforge.net> Patch #101534 has been updated. Project: Category: XML Status: Closed Summary: Use confirmations rather than assertions Follow-Ups: Date: 2000-Sep-15 11:45 By: fdrake Comment: Check it in. Please convert this script to conform to the Python style guide as a second checkin. ------------------------------------------------------- Date: 2000-Sep-18 12:25 By: montanaro Comment: perhaps the confirm function (or something like it) should be added to test_support.py. I see nearly 400 assert statements remaining in Lib/test/test_*.py, all of which will be elided when using python -O. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101534&group_id=5470 From noreply@sourceforge.net Mon Sep 18 22:51:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Sep 2000 14:51:22 -0700 Subject: [Patches] [Patch #101454] Add Unicode support to "exec" and "eval()" Message-ID: <200009182151.OAA16302@delerium.i.sourceforge.net> Patch #101454 has been updated. Project: Category: core (C code) Status: Accepted Summary: Add Unicode support to "exec" and "eval()" Follow-Ups: Date: 2000-Sep-08 13:53 By: lemburg Comment: This patch adds support for Unicode objects to exec and eval(). Unicode objects are converted to default encoded strings prior to processing them with the usual logic. ------------------------------------------------------- Date: 2000-Sep-14 14:53 By: gvanrossum Comment: Go for it. Semi-related question: is there no more elegant way to spell "take this object which I know to be an 8-bit or Unicode string and give me a pointer to a C string containing its 8-bit equivalent, if possible" than PyArg_Parse(obj, "s:tata", &s)? Seems it could use a new C API. ------------------------------------------------------- Date: 2000-Sep-18 14:51 By: lemburg Comment: Even though the (original) patch was already accepted by Guido, I'd like to get some review from others first for this new version. The difference between the original version and this one is a new C API PyString_AsStringAndSize() which encapsulates the logic used in PyArg_Parse(,"s",). Two helpers were added to make use of the new API in the standard PyString_AsString() and PyString_Size() APIs in case a non-string is being passed to these. As a result all code using these two classic APIs will now work with Unicode objects too. This could break some code which does not check for error returns from these APIs though... (the code was buggy before the patch). Conversion from Unicode to strings is done in the usual way: by using the default encoding. With the patch applied, Python's eval() builtin and the "exec" statement will both support Unicode as program string. If nobody objects, I'll check this patch in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101454&group_id=5470 From noreply@sourceforge.net Mon Sep 18 23:08:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Sep 2000 15:08:08 -0700 Subject: [Patches] [Patch #101454] Add Unicode support to "exec" and "eval()" Message-ID: <200009182208.PAA00375@bush.i.sourceforge.net> Patch #101454 has been updated. Project: Category: core (C code) Status: Open Summary: Add Unicode support to "exec" and "eval()" Follow-Ups: Date: 2000-Sep-08 13:53 By: lemburg Comment: This patch adds support for Unicode objects to exec and eval(). Unicode objects are converted to default encoded strings prior to processing them with the usual logic. ------------------------------------------------------- Date: 2000-Sep-14 14:53 By: gvanrossum Comment: Go for it. Semi-related question: is there no more elegant way to spell "take this object which I know to be an 8-bit or Unicode string and give me a pointer to a C string containing its 8-bit equivalent, if possible" than PyArg_Parse(obj, "s:tata", &s)? Seems it could use a new C API. ------------------------------------------------------- Date: 2000-Sep-18 14:51 By: lemburg Comment: Even though the (original) patch was already accepted by Guido, I'd like to get some review from others first for this new version. The difference between the original version and this one is a new C API PyString_AsStringAndSize() which encapsulates the logic used in PyArg_Parse(,"s",). Two helpers were added to make use of the new API in the standard PyString_AsString() and PyString_Size() APIs in case a non-string is being passed to these. As a result all code using these two classic APIs will now work with Unicode objects too. This could break some code which does not check for error returns from these APIs though... (the code was buggy before the patch). Conversion from Unicode to strings is done in the usual way: by using the default encoding. With the patch applied, Python's eval() builtin and the "exec" statement will both support Unicode as program string. If nobody objects, I'll check this patch in. ------------------------------------------------------- Date: 2000-Sep-18 15:08 By: gvanrossum Comment: I'll review it (but not this instant). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101454&group_id=5470 From noreply@sourceforge.net Mon Sep 18 23:37:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Sep 2000 15:37:45 -0700 Subject: [Patches] [Patch #101387] Documenting __contains__ special method Message-ID: <200009182237.PAA18161@delerium.i.sourceforge.net> Patch #101387 has been updated. Project: Category: documentation Status: Open Summary: Documenting __contains__ special method Follow-Ups: Date: 2000-Sep-01 07:38 By: jhylton Comment: Moshe please review but do not accept or check in until we give you the go ahead. These patches arrived too late for 2.0b1. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101387&group_id=5470 From noreply@sourceforge.net Mon Sep 18 23:47:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Sep 2000 15:47:35 -0700 Subject: [Patches] [Patch #101536] httplib should not close socket on zero-length response Message-ID: <200009182247.PAA18524@delerium.i.sourceforge.net> Patch #101536 has been updated. Project: Category: library Status: Accepted Summary: httplib should not close socket on zero-length response Follow-Ups: Date: 2000-Sep-15 10:45 By: jhylton Comment: In the current httplib, an HTTPConnection object calls close on itself when it receives a response with a content-length == 0. I don't think this is a good feature and it is not backwards compatible with the old httplib, which left the socket open. We have had problems with clients of httplib that expect to always read whatever message body is returned. Reading from a socket with no data returns '' (and len('') == 0) which seems completely correct. This patch restores the old behavior and lets clients like urllib call read for any valid response. This patch also restores the set_debuglevel feature. I don't care much if this is included or not, but it added to debug the other problem and it was helpful for that. ------------------------------------------------------- Date: 2000-Sep-18 15:47 By: jhylton Comment: (Greg is on vacation until after 2.0b2.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101536&group_id=5470 From noreply@sourceforge.net Mon Sep 18 23:51:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Sep 2000 15:51:15 -0700 Subject: [Patches] [Patch #101536] httplib should not close socket on zero-length response Message-ID: <200009182251.PAA18610@delerium.i.sourceforge.net> Patch #101536 has been updated. Project: Category: library Status: Accepted Summary: httplib should not close socket on zero-length response Follow-Ups: Date: 2000-Sep-15 10:45 By: jhylton Comment: In the current httplib, an HTTPConnection object calls close on itself when it receives a response with a content-length == 0. I don't think this is a good feature and it is not backwards compatible with the old httplib, which left the socket open. We have had problems with clients of httplib that expect to always read whatever message body is returned. Reading from a socket with no data returns '' (and len('') == 0) which seems completely correct. This patch restores the old behavior and lets clients like urllib call read for any valid response. This patch also restores the set_debuglevel feature. I don't care much if this is included or not, but it added to debug the other problem and it was helpful for that. ------------------------------------------------------- Date: 2000-Sep-18 15:47 By: jhylton Comment: (Greg is on vacation until after 2.0b2.) ------------------------------------------------------- Date: 2000-Sep-18 15:51 By: jhylton Comment: Applied in rev. 1.22 of httplib.py ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101536&group_id=5470 From noreply@sourceforge.net Tue Sep 19 00:14:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Sep 2000 16:14:54 -0700 Subject: [Patches] [Patch #101454] Add Unicode support to "exec" and "eval()" Message-ID: <200009182314.QAA02898@bush.i.sourceforge.net> Patch #101454 has been updated. Project: Category: core (C code) Status: Accepted Summary: Add Unicode support to "exec" and "eval()" Follow-Ups: Date: 2000-Sep-08 13:53 By: lemburg Comment: This patch adds support for Unicode objects to exec and eval(). Unicode objects are converted to default encoded strings prior to processing them with the usual logic. ------------------------------------------------------- Date: 2000-Sep-14 14:53 By: gvanrossum Comment: Go for it. Semi-related question: is there no more elegant way to spell "take this object which I know to be an 8-bit or Unicode string and give me a pointer to a C string containing its 8-bit equivalent, if possible" than PyArg_Parse(obj, "s:tata", &s)? Seems it could use a new C API. ------------------------------------------------------- Date: 2000-Sep-18 14:51 By: lemburg Comment: Even though the (original) patch was already accepted by Guido, I'd like to get some review from others first for this new version. The difference between the original version and this one is a new C API PyString_AsStringAndSize() which encapsulates the logic used in PyArg_Parse(,"s",). Two helpers were added to make use of the new API in the standard PyString_AsString() and PyString_Size() APIs in case a non-string is being passed to these. As a result all code using these two classic APIs will now work with Unicode objects too. This could break some code which does not check for error returns from these APIs though... (the code was buggy before the patch). Conversion from Unicode to strings is done in the usual way: by using the default encoding. With the patch applied, Python's eval() builtin and the "exec" statement will both support Unicode as program string. If nobody objects, I'll check this patch in. ------------------------------------------------------- Date: 2000-Sep-18 15:08 By: gvanrossum Comment: I'll review it (but not this instant). ------------------------------------------------------- Date: 2000-Sep-18 16:14 By: gvanrossum Comment: Fred, this looks good to me. Can you review the docs and then assign it back to Marc-Andre for checkin? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101454&group_id=5470 From noreply@sourceforge.net Tue Sep 19 01:47:14 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Sep 2000 17:47:14 -0700 Subject: [Patches] [Patch #101437] Fix for 110675: GNU pth support Message-ID: <200009190047.RAA06222@bush.i.sourceforge.net> Patch #101437 has been updated. Project: Category: core (C code) Status: Closed Summary: Fix for 110675: GNU pth support Follow-Ups: Date: 2000-Sep-06 17:01 By: adustman Comment: Makes better use of GNU autoconf. configure --with-pth[=DIR] # --with-threads implied Passes test_fork1 and test_thread. Tested with pth-1.3.7. XXX With pth, select() (and others) do not wake up in response to signals. Example: >>> import time >>> time.sleep(10) [hit ctrl-C, no response for 10 seconds] Traceback (most recent call last): File "", line 1, in ? KeyboardInterrupt >>> I have a patch to pth that fixes this that I will try to get incorporated. ------------------------------------------------------- Date: 2000-Sep-15 10:12 By: gvanrossum Comment: Andy, There's one form issue: you shouldn't patch config.h.in, you should patch acconfig.h. And you should make sure that HAVE_PTH is properly in the alphabet between HAVE_LONG_LONG and HAVE_UINTPTR_T. Otherwise I don't have an objection. If I don't hear from you soon I may check it in myself. But since I can't test it I prefer to hear it from you! ------------------------------------------------------- Date: 2000-Sep-15 13:25 By: adustman Comment: This patch should fix the style problems. However, I have noticed a new problem: test_poll dumps core: **Pth** SCHEDULER INTERNAL ERROR: no more thread(s) available to schedule!?!? I suspect this is purely a pth error. ------------------------------------------------------- Date: 2000-Sep-15 13:51 By: adustman Comment: Note: Support for poll() (in selectmodule) did not exist at the time I came up with the original pth support. However, I neglected to test test_poll when submitting the original version of this patch. Error occurs with both pth-1.3.7 and 1.4a2. ------------------------------------------------------- Date: 2000-Sep-15 17:30 By: gvanrossum Comment: I get autoconf errors with this. I think the AC_CHeCK_PTH macro is undefined. ------------------------------------------------------- Date: 2000-Sep-16 07:09 By: gvanrossum Comment: I figured it out: Andy's patch to configure.in requires autoconf to be extended with a macro file that's part of Pth, pth.m4. I'm not comfortable with that. I've asked Andy for a patch that doesn't use AC_CHECK_PTH. ------------------------------------------------------- Date: 2000-Sep-17 15:51 By: adustman Comment: This should meet your specifications. --with-pth is still required to use pth over POSIX threads. ------------------------------------------------------- Date: 2000-Sep-18 17:47 By: gvanrossum Comment: Accepted and checked in. Thanks, Andy!!! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101437&group_id=5470 From noreply@sourceforge.net Tue Sep 19 02:18:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Sep 2000 18:18:23 -0700 Subject: [Patches] [Patch #100927] Fix for broken gethostbyname("0") Message-ID: <200009190118.SAA24201@delerium.i.sourceforge.net> Patch #100927 has been updated. Project: Category: Modules Status: Rejected Summary: Fix for broken gethostbyname("0") Follow-Ups: Date: 2000-Jul-19 01:46 By: effbot Comment: why should this work? why is "gethostbyname" broken if it doesn't support "0" and "-1"? if it's important to support these values, shouldn't they be passed to the function as integers, not as strings? etc. (sorry, I'm usually able to make some kind of sense out of patches, but this one was a bit too cryptic ;-) ------------------------------------------------------- Date: 2000-Jul-20 23:13 By: ppessi Comment: It is not important to support "-1". "0" is INADDR_ANY in dot notation - same as "0.0.0.0" or "0.0.0" or "0.0". gethostbyname() should understand dot notation as well as domain names. For some reason, Windows gethostbyname() does not support "0" (obviously I'm a lazy typer, since I have not noticed that it does not support 0.0 nor 0.0.0 nor 0.0.0.0) unlike Unix platforms. I'll supply another patch ACN. ------------------------------------------------------- Date: 2000-Aug-13 19:49 By: nowonder Comment: As linux supports "0" (as well as "0.0" and friends), this would be nice to reduce platform dependency. But "00" is just as valid (not sure what Windows does with it), so to check this I think a bit more work has to be done. ------------------------------------------------------- Date: 2000-Aug-15 10:50 By: tim_one Comment: Changed status from Open to Postponed. There's been no action on this patch despite comments. If you want it to go into 2.0, address the concerns on Python-Dev Real Quick, and if so I'll Open it again. ------------------------------------------------------- Date: 2000-Sep-16 16:14 By: tim_one Comment: Assigned to Guido because he doubtless knows infinitely more about this than I do (Guido, if you know *anything* this, that's literally true ). ------------------------------------------------------- Date: 2000-Sep-18 18:18 By: gvanrossum Comment: This should not be implemented. You can use "0.0.0.0" if you want to be portable. Note that "0" on Linux takes a strange path through the code: the socket module sees that it doesn't look like a numeric domain (it's not 4 decimal numbers separated by dots) and so passes it to gethostbyname(). Whatever magic gethostbyname() applies on the platform is what you get -- on Linux, it recognizes zero. Lots more would be required to make this portable, so let's not bother. Sorry. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100927&group_id=5470 From noreply@sourceforge.net Tue Sep 19 05:03:51 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Sep 2000 21:03:51 -0700 Subject: [Patches] [Patch #101544] Fix for 110609: Allow large long integers in formatting Message-ID: <200009190403.VAA13534@bush.i.sourceforge.net> Patch #101544 has been updated. Project: Category: core (C code) Status: Open Summary: Fix for 110609: Allow large long integers in formatting Follow-Ups: Date: 2000-Sep-18 21:03 By: gvanrossum Comment: For Tim, because he likes numerical tweakage. (Tim, you may also give this to Marc-Andre, since it affects Unicode.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101544&group_id=5470 From noreply@sourceforge.net Tue Sep 19 05:12:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 18 Sep 2000 21:12:28 -0700 Subject: [Patches] [Patch #101121] cosmetic cleanup of cgi.py, using Guido's style conventions Message-ID: <200009190412.VAA13864@bush.i.sourceforge.net> Patch #101121 has been updated. Project: Category: library Status: Closed Summary: cosmetic cleanup of cgi.py, using Guido's style conventions Follow-Ups: Date: 2000-Aug-08 13:37 By: ping Comment: This is an immediate follow-on to #101120 (i just wanted to keep the semantic and non-semantic changes separate). ------------------------------------------------------- Date: 2000-Aug-15 15:06 By: tim_one Comment: I'm not sure what you mean by "follow-on". If this patch is *independent* of 101120, just Accept it yourself and check it in -- there's no need to go thru a review process for mechanical cleanup. Assigning to you on that basis. Ah, and you *can* check it in, in about 6 hours: you've been added to the Python project as a Developer. That means I get to assign patches to you for review, too From noreply@sourceforge.net Tue Sep 19 11:41:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 03:41:45 -0700 Subject: [Patches] [Patch #101477] Fixes of ReadStream.readline() in UTF-16 and -LE codecs Message-ID: <200009191041.DAA11768@delerium.i.sourceforge.net> Patch #101477 has been updated. Project: Category: library Status: Postponed Summary: Fixes of ReadStream.readline() in UTF-16 and -LE codecs Follow-Ups: Date: 2000-Sep-14 07:09 By: fdrake Comment: Marc-Andre, please review this & decide what should happen next. ------------------------------------------------------- Date: 2000-Sep-18 09:28 By: lemburg Comment: I'm not sure whether this is the right fix: Unicode defines many more line break characters than just LF and the patch will only work correctly on Unix (also note that UTF-16 can be BE and LE -- your fix assumes LE). A true fix would have to also touch the .read() method and implement a true read-ahead buffer strategy to get this done right. ------------------------------------------------------- Date: 2000-Sep-19 03:41 By: lemburg Comment: Postponed until after the Python 2.0b2 release. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101477&group_id=5470 From noreply@sourceforge.net Tue Sep 19 12:15:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 04:15:32 -0700 Subject: [Patches] [Patch #101566] Add fpectl functionality patch for FreeBSD Message-ID: <200009191115.EAA29163@bush.i.sourceforge.net> Patch #101566 has been updated. Project: Category: Modules Status: Open Summary: Add fpectl functionality patch for FreeBSD ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101566&group_id=5470 From noreply@sourceforge.net Tue Sep 19 14:08:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 06:08:24 -0700 Subject: [Patches] [Patch #101537] Include/ceval.h mentions obsolete RET_SAVE macro Message-ID: <200009191308.GAA01050@bush.i.sourceforge.net> Patch #101537 has been updated. Project: Category: core (C code) Status: Closed Summary: Include/ceval.h mentions obsolete RET_SAVE macro ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101537&group_id=5470 From noreply@sourceforge.net Tue Sep 19 14:32:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 06:32:43 -0700 Subject: [Patches] [Patch #101566] Add fpectl functionality patch for FreeBSD Message-ID: <200009191332.GAA18242@delerium.i.sourceforge.net> Patch #101566 has been updated. Project: Category: Modules Status: Open Summary: Add fpectl functionality patch for FreeBSD ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101566&group_id=5470 From noreply@sourceforge.net Tue Sep 19 14:35:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 06:35:49 -0700 Subject: [Patches] [Patch #101566] Add fpectl functionality patch for FreeBSD Message-ID: <200009191335.GAA18413@delerium.i.sourceforge.net> Patch #101566 has been updated. Project: Category: Modules Status: Closed Summary: Add fpectl functionality patch for FreeBSD Follow-Ups: Date: 2000-Sep-19 06:35 By: gvanrossum Comment: Thanks! Checked in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101566&group_id=5470 From noreply@sourceforge.net Tue Sep 19 14:39:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 06:39:13 -0700 Subject: [Patches] [Patch #101423] Fix for 110686: cStringIO.readlines Message-ID: <200009191339.GAA18565@delerium.i.sourceforge.net> Patch #101423 has been updated. Project: Category: library Status: Closed Summary: Fix for 110686: cStringIO.readlines Follow-Ups: Date: 2000-Sep-18 09:34 By: lemburg Comment: The patch looks OK accept that you should replace the "0"s with NULL. Note that for full file object compatibility you will also have to provide a sizehint optional argument. BTW, where's the documentation part of the patch ?-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101423&group_id=5470 From noreply@sourceforge.net Tue Sep 19 15:35:27 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 07:35:27 -0700 Subject: [Patches] [Patch #101481] fix for Bug #113894 in ntpath.py and posixmodule.c Message-ID: <200009191435.HAA04391@bush.i.sourceforge.net> Patch #101481 has been updated. Project: Category: library Status: Open Summary: fix for Bug #113894 in ntpath.py and posixmodule.c Follow-Ups: Date: 2000-Sep-19 07:35 By: montanaro Comment: As if you don't have enough to do, I'm assigning this patch to you, Tim. Don't know who assigned it to me, but I can't test it, since I don't use Windows. Skip ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101481&group_id=5470 From noreply@sourceforge.net Tue Sep 19 15:54:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 07:54:23 -0700 Subject: [Patches] [Patch #101569] URL quote doesn't always quote international characters Message-ID: <200009191454.HAA21478@delerium.i.sourceforge.net> Patch #101569 has been updated. Project: Category: Modules Status: Open Summary: URL quote doesn't always quote international characters ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101569&group_id=5470 From noreply@sourceforge.net Tue Sep 19 15:59:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 07:59:40 -0700 Subject: [Patches] [Patch #101569] URL quote doesn't always quote international characters Message-ID: <200009191459.HAA05321@bush.i.sourceforge.net> Patch #101569 has been updated. Project: Category: Modules Status: Rejected Summary: URL quote doesn't always quote international characters Follow-Ups: Date: 2000-Sep-19 07:59 By: gvanrossum Comment: This is already fixed in the 2.0 CVS tree. This is a duplicate of bug #111951. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101569&group_id=5470 From noreply@sourceforge.net Tue Sep 19 16:58:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 08:58:50 -0700 Subject: [Patches] [Patch #101570] adds correct signatures to handler.py Message-ID: <200009191558.IAA23968@delerium.i.sourceforge.net> Patch #101570 has been updated. Project: Category: XML Status: Open Summary: adds correct signatures to handler.py ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101570&group_id=5470 From noreply@sourceforge.net Tue Sep 19 17:04:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 09:04:44 -0700 Subject: [Patches] [Patch #101570] adds correct signatures to handler.py Message-ID: <200009191604.JAA07965@bush.i.sourceforge.net> Patch #101570 has been updated. Project: Category: XML Status: Open Summary: adds correct signatures to handler.py Follow-Ups: Date: 2000-Sep-19 09:04 By: gvanrossum Comment: Fred, this is for you to do triage on. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101570&group_id=5470 From noreply@sourceforge.net Tue Sep 19 17:06:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 09:06:22 -0700 Subject: [Patches] [Patch #101571] adds make_parser to xml.sax Message-ID: <200009191606.JAA24214@delerium.i.sourceforge.net> Patch #101571 has been updated. Project: Category: XML Status: Open Summary: adds make_parser to xml.sax ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101571&group_id=5470 From noreply@sourceforge.net Tue Sep 19 17:08:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 09:08:29 -0700 Subject: [Patches] [Patch #101572] updates XMLGenerator to new interface Message-ID: <200009191608.JAA24344@delerium.i.sourceforge.net> Patch #101572 has been updated. Project: Category: XML Status: Open Summary: updates XMLGenerator to new interface ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101572&group_id=5470 From noreply@sourceforge.net Tue Sep 19 17:09:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 09:09:47 -0700 Subject: [Patches] [Patch #101573] a first start on updating expatreader.py Message-ID: <200009191609.JAA24383@delerium.i.sourceforge.net> Patch #101573 has been updated. Project: Category: XML Status: Open Summary: a first start on updating expatreader.py ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101573&group_id=5470 From noreply@sourceforge.net Tue Sep 19 17:12:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 09:12:49 -0700 Subject: [Patches] [Patch #101574] a first start on updating expatreader.py Message-ID: <200009191612.JAA24464@delerium.i.sourceforge.net> Patch #101574 has been updated. Project: Category: XML Status: Open Summary: a first start on updating expatreader.py ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101574&group_id=5470 From noreply@sourceforge.net Tue Sep 19 17:14:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 09:14:19 -0700 Subject: [Patches] [Patch #101575] a first start on updating expatreader.py Message-ID: <200009191614.JAA24576@delerium.i.sourceforge.net> Patch #101575 has been updated. Project: Category: XML Status: Open Summary: a first start on updating expatreader.py ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101575&group_id=5470 From noreply@sourceforge.net Tue Sep 19 17:14:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 09:14:42 -0700 Subject: [Patches] [Patch #101570] adds correct signatures to handler.py Message-ID: <200009191614.JAA08322@bush.i.sourceforge.net> Patch #101570 has been updated. Project: Category: XML Status: Accepted Summary: adds correct signatures to handler.py Follow-Ups: Date: 2000-Sep-19 09:04 By: gvanrossum Comment: Fred, this is for you to do triage on. ------------------------------------------------------- Date: 2000-Sep-19 09:14 By: fdrake Comment: This looks good. Check it in! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101570&group_id=5470 From noreply@sourceforge.net Tue Sep 19 17:15:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 09:15:29 -0700 Subject: [Patches] [Patch #101575] a first start on updating expatreader.py Message-ID: <200009191615.JAA24621@delerium.i.sourceforge.net> Patch #101575 has been updated. Project: Category: XML Status: Deleted Summary: a first start on updating expatreader.py ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101575&group_id=5470 From noreply@sourceforge.net Tue Sep 19 17:15:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 09:15:46 -0700 Subject: [Patches] [Patch #101574] a first start on updating expatreader.py Message-ID: <200009191615.JAA24625@delerium.i.sourceforge.net> Patch #101574 has been updated. Project: Category: XML Status: Deleted Summary: a first start on updating expatreader.py ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101574&group_id=5470 From noreply@sourceforge.net Tue Sep 19 18:19:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 10:19:15 -0700 Subject: [Patches] [Patch #101571] adds make_parser to xml.sax Message-ID: <200009191719.KAA27171@delerium.i.sourceforge.net> Patch #101571 has been updated. Project: Category: XML Status: Open Summary: adds make_parser to xml.sax ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101571&group_id=5470 From noreply@sourceforge.net Tue Sep 19 18:19:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 10:19:47 -0700 Subject: [Patches] [Patch #101572] updates XMLGenerator to new interface Message-ID: <200009191719.KAA27189@delerium.i.sourceforge.net> Patch #101572 has been updated. Project: Category: XML Status: Open Summary: updates XMLGenerator to new interface ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101572&group_id=5470 From noreply@sourceforge.net Tue Sep 19 18:20:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 10:20:16 -0700 Subject: [Patches] [Patch #101573] a first start on updating expatreader.py Message-ID: <200009191720.KAA27199@delerium.i.sourceforge.net> Patch #101573 has been updated. Project: Category: XML Status: Open Summary: a first start on updating expatreader.py ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101573&group_id=5470 From noreply@sourceforge.net Tue Sep 19 18:32:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 10:32:40 -0700 Subject: [Patches] [Patch #101572] updates XMLGenerator to new interface Message-ID: <200009191732.KAA27642@delerium.i.sourceforge.net> Patch #101572 has been updated. Project: Category: XML Status: Accepted Summary: updates XMLGenerator to new interface Follow-Ups: Date: 2000-Sep-19 10:32 By: fdrake Comment: Looks good to me -- check it in! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101572&group_id=5470 From noreply@sourceforge.net Tue Sep 19 18:33:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 10:33:11 -0700 Subject: [Patches] [Patch #101571] adds make_parser to xml.sax Message-ID: <200009191733.KAA27651@delerium.i.sourceforge.net> Patch #101571 has been updated. Project: Category: XML Status: Open Summary: adds make_parser to xml.sax Follow-Ups: Date: 2000-Sep-19 10:33 By: loewis Comment: I notice this is an sed-style diff. These have the problem that they won't apply anymore when even slight changes are made to the file. Could you please update the patches as 'content diffs' (diff -c) or 'unified diffs' (diff -u)? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101571&group_id=5470 From noreply@sourceforge.net Tue Sep 19 18:56:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 10:56:07 -0700 Subject: [Patches] [Patch #101571] adds make_parser to xml.sax Message-ID: <200009191756.KAA28596@delerium.i.sourceforge.net> Patch #101571 has been updated. Project: Category: XML Status: Open Summary: adds make_parser to xml.sax Follow-Ups: Date: 2000-Sep-19 10:33 By: loewis Comment: I notice this is an sed-style diff. These have the problem that they won't apply anymore when even slight changes are made to the file. Could you please update the patches as 'content diffs' (diff -c) or 'unified diffs' (diff -u)? ------------------------------------------------------- Date: 2000-Sep-19 10:56 By: fdrake Comment: I've moved things around a little to make this "import *" friendly. I also modified xml.dom.pulldom to use xml.sax.make_parser() instead of naming ExpatParser specifically. This allows the minidom test to pass as well -- this patch had broken the regression test, which is evil. If you're happy with this, please check it in and close the patch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101571&group_id=5470 From noreply@sourceforge.net Tue Sep 19 19:21:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 11:21:46 -0700 Subject: [Patches] [Patch #101387] Documenting __contains__ special method Message-ID: <200009191821.LAA29604@delerium.i.sourceforge.net> Patch #101387 has been updated. Project: Category: documentation Status: Closed Summary: Documenting __contains__ special method Follow-Ups: Date: 2000-Sep-01 07:38 By: jhylton Comment: Moshe please review but do not accept or check in until we give you the go ahead. These patches arrived too late for 2.0b1. ------------------------------------------------------- Date: 2000-Sep-19 11:21 By: fdrake Comment: Checked in a modified version of this patch as Doc/ref/ref3.tex revision 1.50. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101387&group_id=5470 From noreply@sourceforge.net Tue Sep 19 19:31:26 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 11:31:26 -0700 Subject: [Patches] [Patch #101454] Add Unicode support to "exec" and "eval()" Message-ID: <200009191831.LAA29996@delerium.i.sourceforge.net> Patch #101454 has been updated. Project: Category: core (C code) Status: Accepted Summary: Add Unicode support to "exec" and "eval()" Follow-Ups: Date: 2000-Sep-08 13:53 By: lemburg Comment: This patch adds support for Unicode objects to exec and eval(). Unicode objects are converted to default encoded strings prior to processing them with the usual logic. ------------------------------------------------------- Date: 2000-Sep-14 14:53 By: gvanrossum Comment: Go for it. Semi-related question: is there no more elegant way to spell "take this object which I know to be an 8-bit or Unicode string and give me a pointer to a C string containing its 8-bit equivalent, if possible" than PyArg_Parse(obj, "s:tata", &s)? Seems it could use a new C API. ------------------------------------------------------- Date: 2000-Sep-18 14:51 By: lemburg Comment: Even though the (original) patch was already accepted by Guido, I'd like to get some review from others first for this new version. The difference between the original version and this one is a new C API PyString_AsStringAndSize() which encapsulates the logic used in PyArg_Parse(,"s",). Two helpers were added to make use of the new API in the standard PyString_AsString() and PyString_Size() APIs in case a non-string is being passed to these. As a result all code using these two classic APIs will now work with Unicode objects too. This could break some code which does not check for error returns from these APIs though... (the code was buggy before the patch). Conversion from Unicode to strings is done in the usual way: by using the default encoding. With the patch applied, Python's eval() builtin and the "exec" statement will both support Unicode as program string. If nobody objects, I'll check this patch in. ------------------------------------------------------- Date: 2000-Sep-18 15:08 By: gvanrossum Comment: I'll review it (but not this instant). ------------------------------------------------------- Date: 2000-Sep-18 16:14 By: gvanrossum Comment: Fred, this looks good to me. Can you review the docs and then assign it back to Marc-Andre for checkin? ------------------------------------------------------- Date: 2000-Sep-19 11:31 By: fdrake Comment: For the docs, NULL should be marked as \NULL, and the asterisk should not be included in the names of the output variables marked \var; that's part of the type. Please also tell what happens when length==NULL and the string contains null bytes ("If null bytes are present in \var{obj} and \var{length} is \NULL, -1 is returned and TypeError is raised."). In the implementation, the exception raised in that case has a broken message: it's not a Unicode *character* that's expected! Please make the appropriate changes and check this in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101454&group_id=5470 From noreply@sourceforge.net Tue Sep 19 21:29:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 13:29:44 -0700 Subject: [Patches] [Patch #101391] Implemented UserList.__contains__ Message-ID: <200009192029.NAA18396@bush.i.sourceforge.net> Patch #101391 has been updated. Project: Category: library Status: Closed Summary: Implemented UserList.__contains__ Follow-Ups: Date: 2000-Sep-01 07:42 By: jhylton Comment: you know the drill ------------------------------------------------------- Date: 2000-Sep-17 18:38 By: tim_one Comment: Reassigned to me in Moshe's absence. ------------------------------------------------------- Date: 2000-Sep-19 13:29 By: tim_one Comment: Checked in and Closed. Also added new case to test_userlist. Changed Category to Library. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101391&group_id=5470 From noreply@sourceforge.net Tue Sep 19 21:39:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 13:39:47 -0700 Subject: [Patches] [Patch #101481] fix for Bug #113894 in ntpath.py and posixmodule.c Message-ID: <200009192039.NAA02732@delerium.i.sourceforge.net> Patch #101481 has been updated. Project: Category: library Status: Closed Summary: fix for Bug #113894 in ntpath.py and posixmodule.c Follow-Ups: Date: 2000-Sep-19 07:35 By: montanaro Comment: As if you don't have enough to do, I'm assigning this patch to you, Tim. Don't know who assigned it to me, but I can't test it, since I don't use Windows. Skip ------------------------------------------------------- Date: 2000-Sep-19 13:39 By: tim_one Comment: Checked in and Closed. I had already made a similar change to posixmodule.c, so tossed that part of the patch away. Applied the patch to ntpath.py. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101481&group_id=5470 From noreply@sourceforge.net Tue Sep 19 22:08:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 14:08:35 -0700 Subject: [Patches] [Patch #101454] Add Unicode support to "exec" and "eval()" Message-ID: <200009192108.OAA19834@bush.i.sourceforge.net> Patch #101454 has been updated. Project: Category: core (C code) Status: Closed Summary: Add Unicode support to "exec" and "eval()" Follow-Ups: Date: 2000-Sep-08 13:53 By: lemburg Comment: This patch adds support for Unicode objects to exec and eval(). Unicode objects are converted to default encoded strings prior to processing them with the usual logic. ------------------------------------------------------- Date: 2000-Sep-14 14:53 By: gvanrossum Comment: Go for it. Semi-related question: is there no more elegant way to spell "take this object which I know to be an 8-bit or Unicode string and give me a pointer to a C string containing its 8-bit equivalent, if possible" than PyArg_Parse(obj, "s:tata", &s)? Seems it could use a new C API. ------------------------------------------------------- Date: 2000-Sep-18 14:51 By: lemburg Comment: Even though the (original) patch was already accepted by Guido, I'd like to get some review from others first for this new version. The difference between the original version and this one is a new C API PyString_AsStringAndSize() which encapsulates the logic used in PyArg_Parse(,"s",). Two helpers were added to make use of the new API in the standard PyString_AsString() and PyString_Size() APIs in case a non-string is being passed to these. As a result all code using these two classic APIs will now work with Unicode objects too. This could break some code which does not check for error returns from these APIs though... (the code was buggy before the patch). Conversion from Unicode to strings is done in the usual way: by using the default encoding. With the patch applied, Python's eval() builtin and the "exec" statement will both support Unicode as program string. If nobody objects, I'll check this patch in. ------------------------------------------------------- Date: 2000-Sep-18 15:08 By: gvanrossum Comment: I'll review it (but not this instant). ------------------------------------------------------- Date: 2000-Sep-18 16:14 By: gvanrossum Comment: Fred, this looks good to me. Can you review the docs and then assign it back to Marc-Andre for checkin? ------------------------------------------------------- Date: 2000-Sep-19 11:31 By: fdrake Comment: For the docs, NULL should be marked as \NULL, and the asterisk should not be included in the names of the output variables marked \var; that's part of the type. Please also tell what happens when length==NULL and the string contains null bytes ("If null bytes are present in \var{obj} and \var{length} is \NULL, -1 is returned and TypeError is raised."). In the implementation, the exception raised in that case has a broken message: it's not a Unicode *character* that's expected! Please make the appropriate changes and check this in. ------------------------------------------------------- Date: 2000-Sep-19 14:08 By: lemburg Comment: Checked in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101454&group_id=5470 From noreply@sourceforge.net Wed Sep 20 05:06:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Sep 2000 21:06:33 -0700 Subject: [Patches] [Patch #101544] Fix for 110609: Allow large long integers in formatting Message-ID: <200009200406.VAA19129@delerium.i.sourceforge.net> Patch #101544 has been updated. Project: Category: core (C code) Status: Open Summary: Fix for 110609: Allow large long integers in formatting Follow-Ups: Date: 2000-Sep-18 21:03 By: gvanrossum Comment: For Tim, because he likes numerical tweakage. (Tim, you may also give this to Marc-Andre, since it affects Unicode.) ------------------------------------------------------- Date: 2000-Sep-19 21:06 By: tim_one Comment: I'm afraid there are a lot of low-level problems with this patch. Have spent about 90 minutes fixing problems so far, and think it will take another 90 before it's done. Since I'm in the middle of it now, I'd rather finish it than start over from scratch with another stab (and I *do* want to see this get in -- it's a frequent complaint on c.l.py, and is sure *perceived* as a bug today). Examples include: + There was no prototype in scope for stringobject.c's new Py_formatlong when it was referenced in unicodeobject.c. This caused the compiler to assume it returned int instead of PyObject*, and that caused bad code generation. + "Py_formatlong" isn't a proper name for an internal function; if it was meant to be part of the public API, it needed docs. + The new formatlong in unicodeobject.c should have been declared static. + Ubiquitous use of 0 instead of NULL for null pointers; but this is C, not C++. + Non-Guido-like code formatting in small ways. + The logic for "skip" and "sign" is hosed in some cases. For example, >>> "%20x" % 2L**31 ' 80000000' >>> "%.20x" % 2L**31 '8000000000000000000' >>> This because the first "prec > len" loop copies skip+sign characters from the start of buf regardless of whether F_ALT is set (in the 2nd case above, F_ALT is not set, so it was incorrect to copy 2 characters before zero-filling). + The changed test_format failed for me; haven't tracked down why yet. + Not your doing: stringobject.c's existing formatint uses a too-small buffer, under the bad assumption that a C long is at most 2**31. (Speaking of which, why do people constantly try to get a temp buffer down to as few bytes as possible?! The difference between 20 and (say) 256 in a leaf routine is meaningless.) That last one was just to reassure you that I didn't spend the *whole* 90 minutes so far just picking on this patch . ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101544&group_id=5470 From noreply@sourceforge.net Wed Sep 20 08:42:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Sep 2000 00:42:32 -0700 Subject: [Patches] [Patch #101544] Fix for 110609: Allow large long integers in formatting Message-ID: <200009200742.AAA26218@delerium.i.sourceforge.net> Patch #101544 has been updated. Project: Category: core (C code) Status: Open Summary: Fix for 110609: Allow large long integers in formatting Follow-Ups: Date: 2000-Sep-18 21:03 By: gvanrossum Comment: For Tim, because he likes numerical tweakage. (Tim, you may also give this to Marc-Andre, since it affects Unicode.) ------------------------------------------------------- Date: 2000-Sep-19 21:06 By: tim_one Comment: I'm afraid there are a lot of low-level problems with this patch. Have spent about 90 minutes fixing problems so far, and think it will take another 90 before it's done. Since I'm in the middle of it now, I'd rather finish it than start over from scratch with another stab (and I *do* want to see this get in -- it's a frequent complaint on c.l.py, and is sure *perceived* as a bug today). Examples include: + There was no prototype in scope for stringobject.c's new Py_formatlong when it was referenced in unicodeobject.c. This caused the compiler to assume it returned int instead of PyObject*, and that caused bad code generation. + "Py_formatlong" isn't a proper name for an internal function; if it was meant to be part of the public API, it needed docs. + The new formatlong in unicodeobject.c should have been declared static. + Ubiquitous use of 0 instead of NULL for null pointers; but this is C, not C++. + Non-Guido-like code formatting in small ways. + The logic for "skip" and "sign" is hosed in some cases. For example, >>> "%20x" % 2L**31 ' 80000000' >>> "%.20x" % 2L**31 '8000000000000000000' >>> This because the first "prec > len" loop copies skip+sign characters from the start of buf regardless of whether F_ALT is set (in the 2nd case above, F_ALT is not set, so it was incorrect to copy 2 characters before zero-filling). + The changed test_format failed for me; haven't tracked down why yet. + Not your doing: stringobject.c's existing formatint uses a too-small buffer, under the bad assumption that a C long is at most 2**31. (Speaking of which, why do people constantly try to get a temp buffer down to as few bytes as possible?! The difference between 20 and (say) 256 in a leaf routine is meaningless.) That last one was just to reassure you that I didn't spend the *whole* 90 minutes so far just picking on this patch . ------------------------------------------------------- Date: 2000-Sep-20 00:42 By: loewis Comment: It appears that I forgot the snippet diff -u -r2.23 stringobject.h --- stringobject.h 2000/09/19 20:58:38 2.23 +++ stringobject.h 2000/09/20 07:32:28 @@ -68,6 +68,10 @@ #define PyString_InternFromString(cp) PyString_FromString(cp) #endif +/* For use in unicodeobject only. */ +PyObject* Py_formatlong(PyObject *val, int flags, int prec, int type, + char**pbuf, int *plen); + /* Macro, trading safety for speed */ #define PyString_AS_STRING(op) (((PyStringObject *)(op))->ob_sval) #define PyString_GET_SIZE(op) (((PyStringObject *)(op))->ob_size) IOW, Py_formatlong is not intended as an external API. It must have a prefixed name, though, as it is intended to be used across translation units. As for 0 vs NULL, ISO C99 says "An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant." It says that NULL is an implementation-defined null pointer constant, it does not say that either is better than the other. So I feel usage of 0 is perfectly fine in C, with the same rationale that encourages it in C++ over usage of NULL. I'm sorry for the other problems that patch caused. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101544&group_id=5470 From noreply@sourceforge.net Wed Sep 20 08:49:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Sep 2000 00:49:08 -0700 Subject: [Patches] [Patch #101544] Fix for 110609: Allow large long integers in formatting Message-ID: <200009200749.AAA26439@delerium.i.sourceforge.net> Patch #101544 has been updated. Project: Category: core (C code) Status: Open Summary: Fix for 110609: Allow large long integers in formatting Follow-Ups: Date: 2000-Sep-18 21:03 By: gvanrossum Comment: For Tim, because he likes numerical tweakage. (Tim, you may also give this to Marc-Andre, since it affects Unicode.) ------------------------------------------------------- Date: 2000-Sep-19 21:06 By: tim_one Comment: I'm afraid there are a lot of low-level problems with this patch. Have spent about 90 minutes fixing problems so far, and think it will take another 90 before it's done. Since I'm in the middle of it now, I'd rather finish it than start over from scratch with another stab (and I *do* want to see this get in -- it's a frequent complaint on c.l.py, and is sure *perceived* as a bug today). Examples include: + There was no prototype in scope for stringobject.c's new Py_formatlong when it was referenced in unicodeobject.c. This caused the compiler to assume it returned int instead of PyObject*, and that caused bad code generation. + "Py_formatlong" isn't a proper name for an internal function; if it was meant to be part of the public API, it needed docs. + The new formatlong in unicodeobject.c should have been declared static. + Ubiquitous use of 0 instead of NULL for null pointers; but this is C, not C++. + Non-Guido-like code formatting in small ways. + The logic for "skip" and "sign" is hosed in some cases. For example, >>> "%20x" % 2L**31 ' 80000000' >>> "%.20x" % 2L**31 '8000000000000000000' >>> This because the first "prec > len" loop copies skip+sign characters from the start of buf regardless of whether F_ALT is set (in the 2nd case above, F_ALT is not set, so it was incorrect to copy 2 characters before zero-filling). + The changed test_format failed for me; haven't tracked down why yet. + Not your doing: stringobject.c's existing formatint uses a too-small buffer, under the bad assumption that a C long is at most 2**31. (Speaking of which, why do people constantly try to get a temp buffer down to as few bytes as possible?! The difference between 20 and (say) 256 in a leaf routine is meaningless.) That last one was just to reassure you that I didn't spend the *whole* 90 minutes so far just picking on this patch . ------------------------------------------------------- Date: 2000-Sep-20 00:42 By: loewis Comment: It appears that I forgot the snippet diff -u -r2.23 stringobject.h --- stringobject.h 2000/09/19 20:58:38 2.23 +++ stringobject.h 2000/09/20 07:32:28 @@ -68,6 +68,10 @@ #define PyString_InternFromString(cp) PyString_FromString(cp) #endif +/* For use in unicodeobject only. */ +PyObject* Py_formatlong(PyObject *val, int flags, int prec, int type, + char**pbuf, int *plen); + /* Macro, trading safety for speed */ #define PyString_AS_STRING(op) (((PyStringObject *)(op))->ob_sval) #define PyString_GET_SIZE(op) (((PyStringObject *)(op))->ob_size) IOW, Py_formatlong is not intended as an external API. It must have a prefixed name, though, as it is intended to be used across translation units. As for 0 vs NULL, ISO C99 says "An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant." It says that NULL is an implementation-defined null pointer constant, it does not say that either is better than the other. So I feel usage of 0 is perfectly fine in C, with the same rationale that encourages it in C++ over usage of NULL. I'm sorry for the other problems that patch caused. ------------------------------------------------------- Date: 2000-Sep-20 00:49 By: loewis Comment: It also appears that the last chunk of test_format is incorrect, 10 octal is 12, and 10 decimal is 10... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101544&group_id=5470 From noreply@sourceforge.net Wed Sep 20 21:47:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Sep 2000 13:47:41 -0700 Subject: [Patches] [Patch #101536] httplib should not close socket on zero-length response Message-ID: <200009202047.NAA23503@delerium.i.sourceforge.net> Patch #101536 has been updated. Project: Category: library Status: Closed Summary: httplib should not close socket on zero-length response Follow-Ups: Date: 2000-Sep-15 10:45 By: jhylton Comment: In the current httplib, an HTTPConnection object calls close on itself when it receives a response with a content-length == 0. I don't think this is a good feature and it is not backwards compatible with the old httplib, which left the socket open. We have had problems with clients of httplib that expect to always read whatever message body is returned. Reading from a socket with no data returns '' (and len('') == 0) which seems completely correct. This patch restores the old behavior and lets clients like urllib call read for any valid response. This patch also restores the set_debuglevel feature. I don't care much if this is included or not, but it added to debug the other problem and it was helpful for that. ------------------------------------------------------- Date: 2000-Sep-18 15:47 By: jhylton Comment: (Greg is on vacation until after 2.0b2.) ------------------------------------------------------- Date: 2000-Sep-18 15:51 By: jhylton Comment: Applied in rev. 1.22 of httplib.py ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101536&group_id=5470 From noreply@sourceforge.net Wed Sep 20 21:49:30 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Sep 2000 13:49:30 -0700 Subject: [Patches] [Patch #101531] Fix for GC bug #113812 Message-ID: <200009202049.NAA23563@delerium.i.sourceforge.net> Patch #101531 has been updated. Project: Category: core (C code) Status: Closed Summary: Fix for GC bug #113812 Follow-Ups: Date: 2000-Sep-15 11:23 By: gvanrossum Comment: It's your code, Neil! Just check it in, and then mark the patch as closed. ------------------------------------------------------- Date: 2000-Sep-20 13:49 By: gvanrossum Comment: Neil checked it in, so I'm closing it. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101531&group_id=5470 From noreply@sourceforge.net Thu Sep 21 01:49:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Sep 2000 17:49:54 -0700 Subject: [Patches] [Patch #101544] Fix for 110609: Allow large long integers in formatting Message-ID: <200009210049.RAA15246@bush.i.sourceforge.net> Patch #101544 has been updated. Project: Category: core (C code) Status: Open Summary: Fix for 110609: Allow large long integers in formatting Follow-Ups: Date: 2000-Sep-18 21:03 By: gvanrossum Comment: For Tim, because he likes numerical tweakage. (Tim, you may also give this to Marc-Andre, since it affects Unicode.) ------------------------------------------------------- Date: 2000-Sep-19 21:06 By: tim_one Comment: I'm afraid there are a lot of low-level problems with this patch. Have spent about 90 minutes fixing problems so far, and think it will take another 90 before it's done. Since I'm in the middle of it now, I'd rather finish it than start over from scratch with another stab (and I *do* want to see this get in -- it's a frequent complaint on c.l.py, and is sure *perceived* as a bug today). Examples include: + There was no prototype in scope for stringobject.c's new Py_formatlong when it was referenced in unicodeobject.c. This caused the compiler to assume it returned int instead of PyObject*, and that caused bad code generation. + "Py_formatlong" isn't a proper name for an internal function; if it was meant to be part of the public API, it needed docs. + The new formatlong in unicodeobject.c should have been declared static. + Ubiquitous use of 0 instead of NULL for null pointers; but this is C, not C++. + Non-Guido-like code formatting in small ways. + The logic for "skip" and "sign" is hosed in some cases. For example, >>> "%20x" % 2L**31 ' 80000000' >>> "%.20x" % 2L**31 '8000000000000000000' >>> This because the first "prec > len" loop copies skip+sign characters from the start of buf regardless of whether F_ALT is set (in the 2nd case above, F_ALT is not set, so it was incorrect to copy 2 characters before zero-filling). + The changed test_format failed for me; haven't tracked down why yet. + Not your doing: stringobject.c's existing formatint uses a too-small buffer, under the bad assumption that a C long is at most 2**31. (Speaking of which, why do people constantly try to get a temp buffer down to as few bytes as possible?! The difference between 20 and (say) 256 in a leaf routine is meaningless.) That last one was just to reassure you that I didn't spend the *whole* 90 minutes so far just picking on this patch . ------------------------------------------------------- Date: 2000-Sep-20 00:42 By: loewis Comment: It appears that I forgot the snippet diff -u -r2.23 stringobject.h --- stringobject.h 2000/09/19 20:58:38 2.23 +++ stringobject.h 2000/09/20 07:32:28 @@ -68,6 +68,10 @@ #define PyString_InternFromString(cp) PyString_FromString(cp) #endif +/* For use in unicodeobject only. */ +PyObject* Py_formatlong(PyObject *val, int flags, int prec, int type, + char**pbuf, int *plen); + /* Macro, trading safety for speed */ #define PyString_AS_STRING(op) (((PyStringObject *)(op))->ob_sval) #define PyString_GET_SIZE(op) (((PyStringObject *)(op))->ob_size) IOW, Py_formatlong is not intended as an external API. It must have a prefixed name, though, as it is intended to be used across translation units. As for 0 vs NULL, ISO C99 says "An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant." It says that NULL is an implementation-defined null pointer constant, it does not say that either is better than the other. So I feel usage of 0 is perfectly fine in C, with the same rationale that encourages it in C++ over usage of NULL. I'm sorry for the other problems that patch caused. ------------------------------------------------------- Date: 2000-Sep-20 00:49 By: loewis Comment: It also appears that the last chunk of test_format is incorrect, 10 octal is 12, and 10 decimal is 10... ------------------------------------------------------- Date: 2000-Sep-20 17:49 By: tim_one Comment: Martin, these aren't deep issues, This is simply a matter of playing along with the code all around you. The convention for private interface names is to begin them with an underscore, as is plain just from looking at stringobject.c alone. So I renamed the function to _PyString_FormatLong, so it looks like everything else. Same bit with NULL vs 0: when the code you're changing uses NULL *everywhere*, using 0 instead for your own little pieces is a bad idea, and for exactly the same reasons a mixture of indentation or brace styles is a bad idea. There's nothing that can be argued about here. As for the rest, I think you underestimated the intricacy of C's format codes. As other examples here, the blank, plus and zero flags are getting ignored now when formatting a long. This isn't trivial to fix, as the code you built on believed to the depths of its soul that x, X and o conversions can't yield a string with a sign character. So I'm fixing that stuff too. It's all doable, just tedious (I admire your courage in daring to touch any of this code at all <0.9 wink>). I agree with your analysis of the test_format failures, and have fixed them. No offense intended, but it's more evidence that you were in an un-Martin-like careless mood when you created this patch (test_format could not have worked for you either). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101544&group_id=5470 From noreply@sourceforge.net Thu Sep 21 06:24:26 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Sep 2000 22:24:26 -0700 Subject: [Patches] [Patch #101544] Fix for 110609: Allow large long integers in formatting Message-ID: <200009210524.WAA12601@delerium.i.sourceforge.net> Patch #101544 has been updated. Project: Category: core (C code) Status: Rejected Summary: Fix for 110609: Allow large long integers in formatting Follow-Ups: Date: 2000-Sep-18 21:03 By: gvanrossum Comment: For Tim, because he likes numerical tweakage. (Tim, you may also give this to Marc-Andre, since it affects Unicode.) ------------------------------------------------------- Date: 2000-Sep-19 21:06 By: tim_one Comment: I'm afraid there are a lot of low-level problems with this patch. Have spent about 90 minutes fixing problems so far, and think it will take another 90 before it's done. Since I'm in the middle of it now, I'd rather finish it than start over from scratch with another stab (and I *do* want to see this get in -- it's a frequent complaint on c.l.py, and is sure *perceived* as a bug today). Examples include: + There was no prototype in scope for stringobject.c's new Py_formatlong when it was referenced in unicodeobject.c. This caused the compiler to assume it returned int instead of PyObject*, and that caused bad code generation. + "Py_formatlong" isn't a proper name for an internal function; if it was meant to be part of the public API, it needed docs. + The new formatlong in unicodeobject.c should have been declared static. + Ubiquitous use of 0 instead of NULL for null pointers; but this is C, not C++. + Non-Guido-like code formatting in small ways. + The logic for "skip" and "sign" is hosed in some cases. For example, >>> "%20x" % 2L**31 ' 80000000' >>> "%.20x" % 2L**31 '8000000000000000000' >>> This because the first "prec > len" loop copies skip+sign characters from the start of buf regardless of whether F_ALT is set (in the 2nd case above, F_ALT is not set, so it was incorrect to copy 2 characters before zero-filling). + The changed test_format failed for me; haven't tracked down why yet. + Not your doing: stringobject.c's existing formatint uses a too-small buffer, under the bad assumption that a C long is at most 2**31. (Speaking of which, why do people constantly try to get a temp buffer down to as few bytes as possible?! The difference between 20 and (say) 256 in a leaf routine is meaningless.) That last one was just to reassure you that I didn't spend the *whole* 90 minutes so far just picking on this patch . ------------------------------------------------------- Date: 2000-Sep-20 00:42 By: loewis Comment: It appears that I forgot the snippet diff -u -r2.23 stringobject.h --- stringobject.h 2000/09/19 20:58:38 2.23 +++ stringobject.h 2000/09/20 07:32:28 @@ -68,6 +68,10 @@ #define PyString_InternFromString(cp) PyString_FromString(cp) #endif +/* For use in unicodeobject only. */ +PyObject* Py_formatlong(PyObject *val, int flags, int prec, int type, + char**pbuf, int *plen); + /* Macro, trading safety for speed */ #define PyString_AS_STRING(op) (((PyStringObject *)(op))->ob_sval) #define PyString_GET_SIZE(op) (((PyStringObject *)(op))->ob_size) IOW, Py_formatlong is not intended as an external API. It must have a prefixed name, though, as it is intended to be used across translation units. As for 0 vs NULL, ISO C99 says "An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant." It says that NULL is an implementation-defined null pointer constant, it does not say that either is better than the other. So I feel usage of 0 is perfectly fine in C, with the same rationale that encourages it in C++ over usage of NULL. I'm sorry for the other problems that patch caused. ------------------------------------------------------- Date: 2000-Sep-20 00:49 By: loewis Comment: It also appears that the last chunk of test_format is incorrect, 10 octal is 12, and 10 decimal is 10... ------------------------------------------------------- Date: 2000-Sep-20 17:49 By: tim_one Comment: Martin, these aren't deep issues, This is simply a matter of playing along with the code all around you. The convention for private interface names is to begin them with an underscore, as is plain just from looking at stringobject.c alone. So I renamed the function to _PyString_FormatLong, so it looks like everything else. Same bit with NULL vs 0: when the code you're changing uses NULL *everywhere*, using 0 instead for your own little pieces is a bad idea, and for exactly the same reasons a mixture of indentation or brace styles is a bad idea. There's nothing that can be argued about here. As for the rest, I think you underestimated the intricacy of C's format codes. As other examples here, the blank, plus and zero flags are getting ignored now when formatting a long. This isn't trivial to fix, as the code you built on believed to the depths of its soul that x, X and o conversions can't yield a string with a sign character. So I'm fixing that stuff too. It's all doable, just tedious (I admire your courage in daring to touch any of this code at all <0.9 wink>). I agree with your analysis of the test_format failures, and have fixed them. No offense intended, but it's more evidence that you were in an un-Martin-like careless mood when you created this patch (test_format could not have worked for you either). ------------------------------------------------------- Date: 2000-Sep-20 22:24 By: tim_one Comment: Rejected this specific patch for the reasons given, but am checking in a derivative that I hope gets all the endcases right; also added dozens of non-trivial new test cases to test_format.py. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101544&group_id=5470 From noreply@sourceforge.net Thu Sep 21 09:25:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 21 Sep 2000 01:25:39 -0700 Subject: [Patches] [Patch #101572] updates XMLGenerator to new interface Message-ID: <200009210825.BAA31072@bush.i.sourceforge.net> Patch #101572 has been updated. Project: Category: XML Status: Closed Summary: updates XMLGenerator to new interface Follow-Ups: Date: 2000-Sep-19 10:32 By: fdrake Comment: Looks good to me -- check it in! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101572&group_id=5470 From noreply@sourceforge.net Thu Sep 21 09:25:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 21 Sep 2000 01:25:55 -0700 Subject: [Patches] [Patch #101570] adds correct signatures to handler.py Message-ID: <200009210825.BAA31165@bush.i.sourceforge.net> Patch #101570 has been updated. Project: Category: XML Status: Closed Summary: adds correct signatures to handler.py Follow-Ups: Date: 2000-Sep-19 09:04 By: gvanrossum Comment: Fred, this is for you to do triage on. ------------------------------------------------------- Date: 2000-Sep-19 09:14 By: fdrake Comment: This looks good. Check it in! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101570&group_id=5470 From noreply@sourceforge.net Thu Sep 21 09:34:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 21 Sep 2000 01:34:44 -0700 Subject: [Patches] [Patch #101571] adds make_parser to xml.sax Message-ID: <200009210834.BAA31420@bush.i.sourceforge.net> Patch #101571 has been updated. Project: Category: XML Status: Closed Summary: adds make_parser to xml.sax Follow-Ups: Date: 2000-Sep-19 10:33 By: loewis Comment: I notice this is an sed-style diff. These have the problem that they won't apply anymore when even slight changes are made to the file. Could you please update the patches as 'content diffs' (diff -c) or 'unified diffs' (diff -u)? ------------------------------------------------------- Date: 2000-Sep-19 10:56 By: fdrake Comment: I've moved things around a little to make this "import *" friendly. I also modified xml.dom.pulldom to use xml.sax.make_parser() instead of naming ExpatParser specifically. This allows the minidom test to pass as well -- this patch had broken the regression test, which is evil. If you're happy with this, please check it in and close the patch. ------------------------------------------------------- Date: 2000-Sep-21 01:34 By: larsga Comment: Committed with Fred's improvements. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101571&group_id=5470 From noreply@sourceforge.net Thu Sep 21 12:57:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 21 Sep 2000 04:57:04 -0700 Subject: [Patches] [Patch #101595] ob_type in deallocator function Message-ID: <200009211157.EAA06255@bush.i.sourceforge.net> Patch #101595 has been updated. Project: Category: core (C code) Status: Open Summary: ob_type in deallocator function ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101595&group_id=5470 From noreply@sourceforge.net Thu Sep 21 17:14:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 21 Sep 2000 09:14:36 -0700 Subject: [Patches] [Patch #101595] ob_type in deallocator function Message-ID: <200009211614.JAA16500@bush.i.sourceforge.net> Patch #101595 has been updated. Project: Category: core (C code) Status: Open Summary: ob_type in deallocator function Follow-Ups: Date: 2000-Sep-21 09:14 By: gvanrossum Comment: Hmm, he may be right. I think that setting the ob_type pointer to zero before calling the dealloc function (which only happens in Py_DEBUG mode) is indeed a bug! For example, deallocating a class instance with a __del__ destructor that revives the object would be a disaster, since the revived object would not have a type any more. Given to Neil, who can judge why this was done, and may check in a fix if he agrees. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101595&group_id=5470 From noreply@sourceforge.net Thu Sep 21 17:25:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 21 Sep 2000 09:25:48 -0700 Subject: [Patches] [Patch #101595] ob_type in deallocator function Message-ID: <200009211625.JAA16944@bush.i.sourceforge.net> Patch #101595 has been updated. Project: Category: core (C code) Status: Closed Summary: ob_type in deallocator function Follow-Ups: Date: 2000-Sep-21 09:14 By: gvanrossum Comment: Hmm, he may be right. I think that setting the ob_type pointer to zero before calling the dealloc function (which only happens in Py_DEBUG mode) is indeed a bug! For example, deallocating a class instance with a __del__ destructor that revives the object would be a disaster, since the revived object would not have a type any more. Given to Neil, who can judge why this was done, and may check in a fix if he agrees. ------------------------------------------------------- Date: 2000-Sep-21 09:25 By: gvanrossum Comment: Never mind, Neil. It's got nothing to do with your code. I'll just get rid of the bit that sets ob_type to NULL, it should't break anything. Checked in. Thanks, Toby! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101595&group_id=5470 From noreply@sourceforge.net Thu Sep 21 18:03:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 21 Sep 2000 10:03:01 -0700 Subject: [Patches] [Patch #101573] a first start on updating expatreader.py Message-ID: <200009211703.KAA18566@bush.i.sourceforge.net> Patch #101573 has been updated. Project: Category: XML Status: Open Summary: a first start on updating expatreader.py Follow-Ups: Date: 2000-Sep-21 10:03 By: fdrake Comment: I can't accept this until corresponding patches are made elsewhere in the xml package. The DOM implementation in particular requires updating, or the regression test will fail. I've sent mail to Paul Prescod and Lars Garshol about this. They have a short timeframe if they want to avoid me doing to work and forcing compliance with the coding standard. ;-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101573&group_id=5470 From noreply@sourceforge.net Thu Sep 21 18:44:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 21 Sep 2000 10:44:07 -0700 Subject: [Patches] [Patch #101512] Support parsing of already opened file objects Message-ID: <200009211744.KAA20251@bush.i.sourceforge.net> Patch #101512 has been updated. Project: Category: XML Status: Closed Summary: Support parsing of already opened file objects Follow-Ups: Date: 2000-Sep-14 11:15 By: jhylton Comment: I don't particularly care for this interface change. It appears that the parser will close the file if passed as an argument. Since the parser did not open the file, it should not close it. It seems to me that this feature should be a separate method. Also, there seem to be a lot of style problems with this code. There is inconsistent use of whitespace around ()s and =s. It should be consistent above all! And it should use the approved Python style. ------------------------------------------------------- Date: 2000-Sep-14 12:21 By: prescod Comment: This isn't an interface change, it just makes the interface work the way it says it does. If fixes a FIXME. A separate method is a good idea but it would have to be agreed upon by the xml-sig (or at least implemented by Lars, the main SAX maintainer). I see that as part of the larger refactoring that Lars is doing. I'm not clear what line of code closes the file. It looks to me like it just goes out of scope still open. ------------------------------------------------------- Date: 2000-Sep-14 14:08 By: fdrake Comment: I'm hesitant to approve this myself; I don't like the overloading. (Though I agree that this simply brings the implementation into line with the documentation, such as it is.) The Java equivelent uses an overloaded parse() method, but Java provides direct support for this in the language definition. I think the Python SAX2 definition should provide separate methods. Let's wait for Lars to weigh in on the API issues. ------------------------------------------------------- Date: 2000-Sep-15 04:03 By: gvanrossum Comment: I would approve this if it took care of Jeremy's concern: if the file is opened by the caller, the callee should not close it. Given that Java overloads parse(), the Python approach of testing for a file is fine; I don't think it's necessary to dd a new method. ------------------------------------------------------- Date: 2000-Sep-15 06:53 By: prescod Comment: I believe Jeremy to be wrong. If you do a "grep" in the xml/sig directory you'll find that files are never closed. They just go out of scope. If we opened the file then it will close when it goes out of scope. If the caller opened the file, it will close when they throw away their last reference to it. The wonders of reference counting! ------------------------------------------------------- Date: 2000-Sep-15 06:56 By: jhylton Comment: It sounds like the code has the opposite sort of bug, then. It opens file and does not explicitly close them. The code should not depend on the reference counting mechanism to close files. ------------------------------------------------------- Date: 2000-Sep-15 07:29 By: prescod Comment: The word bug is too strong when all the module does is depend on documented Python features. Allowing auto-closing of files is one of the major arguments for Python's reference counting (according to the Python FAQ) and an advantage of Python over Java et al. If you do explicit closing you reintroduce the same lifetime issues that make pointer handling such a hassle in C++. In this particular case, the lifetime of the file object is pretty easy to track (barring funny stuff) so adding a close would be relatively easy and would make portability to JPython easier. I would like to hear what the BeOpen concensus is so that I can add it to my personal style guide. ------------------------------------------------------- Date: 2000-Sep-15 07:52 By: gvanrossum Comment: BeOpen doesn't enter into it. :-) PythonLabs is what counts. Consensus is had has been as Jeremy says: iff you open a file, you should close it. Note: adding close() should be a separate patch. Fred: you can accept this one once the close() patch is in. ------------------------------------------------------- Date: 2000-Sep-15 11:32 By: prescod Comment: The features are intertwined. The best implementation strategy requires a local rewrite of the method. Therefore the previous patch becomes redundant and unhelpful. ------------------------------------------------------- Date: 2000-Sep-21 10:44 By: fdrake Comment: Checking in a (slightly) modified version of this patch as Lib/xml/sax/xmlreader.py revision 1.4. Also fixes a few style nits. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101512&group_id=5470 From noreply@sourceforge.net Thu Sep 21 23:09:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 21 Sep 2000 15:09:44 -0700 Subject: [Patches] [Patch #101558] Fix for #112289 Message-ID: <200009212209.PAA22856@delerium.i.sourceforge.net> Patch #101558 has been updated. Project: Category: Build Status: Open Summary: Fix for #112289 Follow-Ups: Date: 2000-Sep-18 07:22 By: gvanrossum Comment: Trent, if this looks okay to you, please check it in and close it. If you don't have time for this, say so and reassign it to someone in the PyLabs group. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101558&group_id=5470 From noreply@sourceforge.net Thu Sep 21 23:15:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 21 Sep 2000 15:15:50 -0700 Subject: [Patches] [Patch #101558] Fix for #112289 Message-ID: <200009212215.PAA23055@delerium.i.sourceforge.net> Patch #101558 has been updated. Project: Category: Build Status: Closed Summary: Fix for #112289 Follow-Ups: Date: 2000-Sep-18 07:22 By: gvanrossum Comment: Trent, if this looks okay to you, please check it in and close it. If you don't have time for this, say so and reassign it to someone in the PyLabs group. ------------------------------------------------------- Date: 2000-Sep-21 15:15 By: gvanrossum Comment: Checked in, modified to also support __OpenBSD__ in the same way. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101558&group_id=5470 From noreply@sourceforge.net Thu Sep 21 23:28:20 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 21 Sep 2000 15:28:20 -0700 Subject: [Patches] [Patch #101388] Backward compatibility hook Message-ID: <200009212228.PAA23604@delerium.i.sourceforge.net> Patch #101388 has been updated. Project: Category: documentation Status: Closed Summary: Backward compatibility hook Follow-Ups: Date: 2000-Sep-01 07:41 By: jhylton Comment: same deal: postponed for now, but may be considered post 2.0b1 ------------------------------------------------------- Date: 2000-Sep-15 07:17 By: fdrake Comment: The test using sys.hexversion may be more readable if sys.version_info is used instead: if sys.version_info < (2, 0): ... ------------------------------------------------------- Date: 2000-Sep-15 09:51 By: gvanrossum Comment: This is a doc update. But I believe that it's backwards. The proper solution is to let __getslice__(self, lo, hi) call self.__getitem__(slice(lo, hi)) -- or self[lo:hi:]; and similar for the others. Then you can write code in __getitem__ that handles slice objects (and tuples of slice objects). Why does he use max(i,0) etc.? I don't think that's needed or correct! The version check could be done to make it a bit faster. ------------------------------------------------------- Date: 2000-Sep-18 04:23 By: ods Comment: Why using max(i, 0) Let seq is the sequence with 5 items. Expression seq[-10:] is equivalent for seq.__getslice__(-5, sys.maxint) or seq.__getitem__(slice(-10, None, None)) but not seq.__getitem__(slice(-5, None, None))! ------------------------------------------------------- Date: 2000-Sep-18 07:46 By: gvanrossum Comment: OK, I understand. Fred, if you want to do something with this, please use the version check you like and add a comment explaining the max() (if it's not already explained nearby). ------------------------------------------------------- Date: 2000-Sep-21 15:28 By: fdrake Comment: Checked in with additional explanation in Doc/ref/ref3.tex revision 1.52. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101388&group_id=5470 From noreply@sourceforge.net Fri Sep 22 05:35:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 21 Sep 2000 21:35:50 -0700 Subject: [Patches] [Patch #101412] add gc.DEBUG_SAVEALL option, gc_str fix Message-ID: <200009220435.VAA12266@bush.i.sourceforge.net> Patch #101412 has been updated. Project: Category: core (C code) Status: Open Summary: add gc.DEBUG_SAVEALL option, gc_str fix Follow-Ups: Date: 2000-Sep-03 20:13 By: marangoz Comment: Looks good. I approve the str fix. One nit: "else" clauses usually go to a new line in the Python source. Make it "else if" on a new line. Questions: - DEBUG_LEAK now includes SAVEALL. The regression test suite sets DEBUG_LEAK by default. It used to report a bunch of objects during test_gc. Now it will collect the detected cycles in the suite. Should regrtest.py report them somehow? - After the regression test, gc.garbage contains an A instance and an empty list. I think they're created by test_gc. Can't they be cleared? We can assign gc.garbage = [], but this doesn't clear anything. - test_gc/test_saveall has gc.set_debug(0), followed immediately by gc.set_debug(gc.DEBUG_SAVEALL). Is this on purpose or is it a typo? BTW, I don't quite understand why this function does what it does... Could you elaborate on it? ------------------------------------------------------- Date: 2000-Sep-04 07:05 By: nascheme Comment: - regrtest will print the repr of cyclic garbage found if -l option is specified and -q is not - put else on newline in accordance with Python style - constrain debugging options during test_gc (don't enabled DEBUG_LEAK) - fix test_gc to remove garbage from gc.garbage ------------------------------------------------------- Date: 2000-Sep-21 21:35 By: tim_one Comment: Is there a reason this patch is just sitting here? *Looks* like all the concerns were addressed two weeks ago. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101412&group_id=5470 From noreply@sourceforge.net Fri Sep 22 07:17:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 21 Sep 2000 23:17:23 -0700 Subject: [Patches] [Patch #101233] PyModule_AddObject() and friends Message-ID: <200009220617.XAA07559@delerium.i.sourceforge.net> Patch #101233 has been updated. Project: Category: core (C code) Status: Open Summary: PyModule_AddObject() and friends Follow-Ups: Date: 2000-Aug-19 10:17 By: marangoz Comment: Looks good. BDFL need to Pronounce on API issues. What amount of changes would this imply in the distrib? Have patch? (the names could be tuned later directly in the patch ) ------------------------------------------------------- Date: 2000-Aug-19 21:31 By: tim_one Comment: Assigned to Guido because, as Vlad says, he needs to Prounounce on the idea. Guido, the point here is to provide a single implementation to replace all the repeated and inconsistent functions and macros that modules are defining today for use in their init functions. Was discussed on Python-Dev and was well-received there. Andrew, I dislike the name PyModule_AddConstantLong, because that Python ints *happen* to be C longs should be an implementation detail. Since the function is actually adding a Python int, I'm afraid I like PyModule_AddConstantInt better. Oh, yuck. Ah! PyModule_AddConstantPyInt. ------------------------------------------------------- Date: 2000-Aug-21 17:46 By: gvanrossum Comment: I like the idea fine, but don't think it's important enough to rush it into 2.0. Anyway it needs docs for api.tex. AddConstantPyInt is a bad name becase "PyInt" suggests that the argument is a Python int object, not a C int. Suggestion: PyModule_AddIntConstant and PyModule_AddStringConstant. I'm a bit worried by the implied DECREF in PyModule_AddObject -- this should better go into the other two, or the name should be changed, maybe to _AddNewObject. ------------------------------------------------------- Date: 2000-Sep-15 09:41 By: gvanrossum Comment: Andrew, this was revived. Can you address the comments? I'm not against adding this to 2.0b2, although there are undoubtedly more important things to do. ------------------------------------------------------- Date: 2000-Sep-21 23:17 By: fdrake Comment: Revised version of the patch that addess the concerns noted, adds API documentation. Andrew, please review. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101233&group_id=5470 From noreply@sourceforge.net Fri Sep 22 13:54:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 22 Sep 2000 05:54:55 -0700 Subject: [Patches] [Patch #101416] coax _sre.c into using Py_GetRecursionLimit() Message-ID: <200009221254.FAA29814@bush.i.sourceforge.net> Patch #101416 has been updated. Project: Category: Modules Status: Open Summary: coax _sre.c into using Py_GetRecursionLimit() Follow-Ups: Date: 2000-Sep-04 09:02 By: montanaro Comment: seems obvious that Fredrik should be the one to handle this... ------------------------------------------------------- Date: 2000-Sep-15 07:21 By: fdrake Comment: The declaration of rlimit should be wrapped in #ifdef USE_RECURSION_LIMIT / #endif, since it isn't used otherwise. ------------------------------------------------------- Date: 2000-Sep-15 08:26 By: montanaro Comment: thanks - new version adds the appropriate ifdef ------------------------------------------------------- Date: 2000-Sep-22 05:54 By: fdrake Comment: Fredrik, are there problems with this patch? Does it not make sense? Please take action on this. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101416&group_id=5470 From noreply@sourceforge.net Fri Sep 22 14:58:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 22 Sep 2000 06:58:53 -0700 Subject: [Patches] [Patch #101412] add gc.DEBUG_SAVEALL option, gc_str fix Message-ID: <200009221358.GAA32259@bush.i.sourceforge.net> Patch #101412 has been updated. Project: Category: core (C code) Status: Open Summary: add gc.DEBUG_SAVEALL option, gc_str fix Follow-Ups: Date: 2000-Sep-03 20:13 By: marangoz Comment: Looks good. I approve the str fix. One nit: "else" clauses usually go to a new line in the Python source. Make it "else if" on a new line. Questions: - DEBUG_LEAK now includes SAVEALL. The regression test suite sets DEBUG_LEAK by default. It used to report a bunch of objects during test_gc. Now it will collect the detected cycles in the suite. Should regrtest.py report them somehow? - After the regression test, gc.garbage contains an A instance and an empty list. I think they're created by test_gc. Can't they be cleared? We can assign gc.garbage = [], but this doesn't clear anything. - test_gc/test_saveall has gc.set_debug(0), followed immediately by gc.set_debug(gc.DEBUG_SAVEALL). Is this on purpose or is it a typo? BTW, I don't quite understand why this function does what it does... Could you elaborate on it? ------------------------------------------------------- Date: 2000-Sep-04 07:05 By: nascheme Comment: - regrtest will print the repr of cyclic garbage found if -l option is specified and -q is not - put else on newline in accordance with Python style - constrain debugging options during test_gc (don't enabled DEBUG_LEAK) - fix test_gc to remove garbage from gc.garbage ------------------------------------------------------- Date: 2000-Sep-21 21:35 By: tim_one Comment: Is there a reason this patch is just sitting here? *Looks* like all the concerns were addressed two weeks ago. ------------------------------------------------------- Date: 2000-Sep-22 06:58 By: nascheme Comment: Is this patch is okay for 2.0? If so I can check it in and close the patch. I was planning to wait for post 2.0. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101412&group_id=5470 From noreply@sourceforge.net Fri Sep 22 15:08:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 22 Sep 2000 07:08:49 -0700 Subject: [Patches] [Patch #101412] add gc.DEBUG_SAVEALL option, gc_str fix Message-ID: <200009221408.HAA24965@delerium.i.sourceforge.net> Patch #101412 has been updated. Project: Category: core (C code) Status: Accepted Summary: add gc.DEBUG_SAVEALL option, gc_str fix Follow-Ups: Date: 2000-Sep-03 20:13 By: marangoz Comment: Looks good. I approve the str fix. One nit: "else" clauses usually go to a new line in the Python source. Make it "else if" on a new line. Questions: - DEBUG_LEAK now includes SAVEALL. The regression test suite sets DEBUG_LEAK by default. It used to report a bunch of objects during test_gc. Now it will collect the detected cycles in the suite. Should regrtest.py report them somehow? - After the regression test, gc.garbage contains an A instance and an empty list. I think they're created by test_gc. Can't they be cleared? We can assign gc.garbage = [], but this doesn't clear anything. - test_gc/test_saveall has gc.set_debug(0), followed immediately by gc.set_debug(gc.DEBUG_SAVEALL). Is this on purpose or is it a typo? BTW, I don't quite understand why this function does what it does... Could you elaborate on it? ------------------------------------------------------- Date: 2000-Sep-04 07:05 By: nascheme Comment: - regrtest will print the repr of cyclic garbage found if -l option is specified and -q is not - put else on newline in accordance with Python style - constrain debugging options during test_gc (don't enabled DEBUG_LEAK) - fix test_gc to remove garbage from gc.garbage ------------------------------------------------------- Date: 2000-Sep-21 21:35 By: tim_one Comment: Is there a reason this patch is just sitting here? *Looks* like all the concerns were addressed two weeks ago. ------------------------------------------------------- Date: 2000-Sep-22 06:58 By: nascheme Comment: Is this patch is okay for 2.0? If so I can check it in and close the patch. I was planning to wait for post 2.0. ------------------------------------------------------- Date: 2000-Sep-22 07:08 By: gvanrossum Comment: *Unless* you fear that this would destabilize things (which are coming together so nicely), I'd suggest to check this in before beta2 goes out! Accepted and Assigned to Neil for this reason. It doesn't *look* like there's anything tricky going on, but I'll leave it to your judgement. If you don't want to check it in after all, please log in to sourceforge and change the status to Postponed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101412&group_id=5470 From noreply@sourceforge.net Fri Sep 22 15:47:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 22 Sep 2000 07:47:21 -0700 Subject: [Patches] [Patch #101606] threads and __del__ Message-ID: <200009221447.HAA26343@delerium.i.sourceforge.net> Patch #101606 has been updated. Project: Category: None Status: Open Summary: threads and __del__ ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101606&group_id=5470 From noreply@sourceforge.net Fri Sep 22 16:06:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 22 Sep 2000 08:06:58 -0700 Subject: [Patches] [Patch #101606] threads and __del__ Message-ID: <200009221506.IAA27070@delerium.i.sourceforge.net> Patch #101606 has been updated. Project: Category: core (C code) Status: Open Summary: threads and __del__ Follow-Ups: Date: 2000-Sep-22 08:06 By: gvanrossum Comment: Works fine for me. Assigned to Tim for review since he's the race condition czar. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101606&group_id=5470 From Fredrik Lundh" Message-ID: <006601c024ab$5b385580$766940d5@hagrid> > Fredrik, are there problems with this patch? Does it not make sense? not really -- are recursive sre_match calls really equi- valent to nested eval_code2 calls? I'm sceptical, but I might be wrong. Feel free to convince me that I am wrong; otherwise, I'd rather leave things as they are for now (with the goal of making a "stackless" SRE for 2.1) From noreply@sourceforge.net Fri Sep 22 16:45:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 22 Sep 2000 08:45:42 -0700 Subject: [Patches] [Patch #101412] add gc.DEBUG_SAVEALL option, gc_str fix Message-ID: <200009221545.IAA04086@bush.i.sourceforge.net> Patch #101412 has been updated. Project: Category: core (C code) Status: Closed Summary: add gc.DEBUG_SAVEALL option, gc_str fix Follow-Ups: Date: 2000-Sep-03 20:13 By: marangoz Comment: Looks good. I approve the str fix. One nit: "else" clauses usually go to a new line in the Python source. Make it "else if" on a new line. Questions: - DEBUG_LEAK now includes SAVEALL. The regression test suite sets DEBUG_LEAK by default. It used to report a bunch of objects during test_gc. Now it will collect the detected cycles in the suite. Should regrtest.py report them somehow? - After the regression test, gc.garbage contains an A instance and an empty list. I think they're created by test_gc. Can't they be cleared? We can assign gc.garbage = [], but this doesn't clear anything. - test_gc/test_saveall has gc.set_debug(0), followed immediately by gc.set_debug(gc.DEBUG_SAVEALL). Is this on purpose or is it a typo? BTW, I don't quite understand why this function does what it does... Could you elaborate on it? ------------------------------------------------------- Date: 2000-Sep-04 07:05 By: nascheme Comment: - regrtest will print the repr of cyclic garbage found if -l option is specified and -q is not - put else on newline in accordance with Python style - constrain debugging options during test_gc (don't enabled DEBUG_LEAK) - fix test_gc to remove garbage from gc.garbage ------------------------------------------------------- Date: 2000-Sep-21 21:35 By: tim_one Comment: Is there a reason this patch is just sitting here? *Looks* like all the concerns were addressed two weeks ago. ------------------------------------------------------- Date: 2000-Sep-22 06:58 By: nascheme Comment: Is this patch is okay for 2.0? If so I can check it in and close the patch. I was planning to wait for post 2.0. ------------------------------------------------------- Date: 2000-Sep-22 07:08 By: gvanrossum Comment: *Unless* you fear that this would destabilize things (which are coming together so nicely), I'd suggest to check this in before beta2 goes out! Accepted and Assigned to Neil for this reason. It doesn't *look* like there's anything tricky going on, but I'll leave it to your judgement. If you don't want to check it in after all, please log in to sourceforge and change the status to Postponed. ------------------------------------------------------- Date: 2000-Sep-22 08:45 By: nascheme Comment: Checked in. Guys, _please_ review my diffs. The original patch did not apply cleanly. Also, I found some problems with the patch which I tried to fix. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101412&group_id=5470 From noreply@sourceforge.net Fri Sep 22 20:13:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 22 Sep 2000 12:13:58 -0700 Subject: [Patches] [Patch #101233] PyModule_AddObject() and friends Message-ID: <200009221913.MAA12547@bush.i.sourceforge.net> Patch #101233 has been updated. Project: Category: core (C code) Status: Open Summary: PyModule_AddObject() and friends Follow-Ups: Date: 2000-Aug-19 10:17 By: marangoz Comment: Looks good. BDFL need to Pronounce on API issues. What amount of changes would this imply in the distrib? Have patch? (the names could be tuned later directly in the patch ) ------------------------------------------------------- Date: 2000-Aug-19 21:31 By: tim_one Comment: Assigned to Guido because, as Vlad says, he needs to Prounounce on the idea. Guido, the point here is to provide a single implementation to replace all the repeated and inconsistent functions and macros that modules are defining today for use in their init functions. Was discussed on Python-Dev and was well-received there. Andrew, I dislike the name PyModule_AddConstantLong, because that Python ints *happen* to be C longs should be an implementation detail. Since the function is actually adding a Python int, I'm afraid I like PyModule_AddConstantInt better. Oh, yuck. Ah! PyModule_AddConstantPyInt. ------------------------------------------------------- Date: 2000-Aug-21 17:46 By: gvanrossum Comment: I like the idea fine, but don't think it's important enough to rush it into 2.0. Anyway it needs docs for api.tex. AddConstantPyInt is a bad name becase "PyInt" suggests that the argument is a Python int object, not a C int. Suggestion: PyModule_AddIntConstant and PyModule_AddStringConstant. I'm a bit worried by the implied DECREF in PyModule_AddObject -- this should better go into the other two, or the name should be changed, maybe to _AddNewObject. ------------------------------------------------------- Date: 2000-Sep-15 09:41 By: gvanrossum Comment: Andrew, this was revived. Can you address the comments? I'm not against adding this to 2.0b2, although there are undoubtedly more important things to do. ------------------------------------------------------- Date: 2000-Sep-21 23:17 By: fdrake Comment: Revised version of the patch that addess the concerns noted, adds API documentation. Andrew, please review. ------------------------------------------------------- Date: 2000-Sep-22 12:13 By: fdrake Comment: Guido, Andrew is appearantly too busy to review this. Can you take a look at it? Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101233&group_id=5470 From skip@mojam.com (Skip Montanaro) Fri Sep 22 20:41:58 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Fri, 22 Sep 2000 14:41:58 -0500 (CDT) Subject: [Patches] Re: [Patch #101416] coax _sre.c into using Py_GetRecursionLimit() In-Reply-To: <006601c024ab$5b385580$766940d5@hagrid> References: <200009221254.FAA29814@bush.i.sourceforge.net> <006601c024ab$5b385580$766940d5@hagrid> Message-ID: <14795.46598.789576.23886@beluga.mojam.com> >> Fredrik, are there problems with this patch? Does it not make sense? Fredrik> not really -- are recursive sre_match calls really equi- Fredrik> valent to nested eval_code2 calls? I was skeptical as well, but I needed something I could twiddle from the Python level to keep _sre from giving up too early. If you don't accept the current patch, can you at least look at doing something similar through a Python-visible variable in re or _sre? The problems I had didn't occur using the original re. Either it had a deeper stack limit or chewed less stack space for "bad" re's. Skip From noreply@sourceforge.net Sat Sep 23 04:26:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 22 Sep 2000 20:26:29 -0700 Subject: [Patches] [Patch #101233] PyModule_AddObject() and friends Message-ID: <200009230326.UAA29856@bush.i.sourceforge.net> Patch #101233 has been updated. Project: Category: core (C code) Status: Closed Summary: PyModule_AddObject() and friends Follow-Ups: Date: 2000-Aug-19 10:17 By: marangoz Comment: Looks good. BDFL need to Pronounce on API issues. What amount of changes would this imply in the distrib? Have patch? (the names could be tuned later directly in the patch ) ------------------------------------------------------- Date: 2000-Aug-19 21:31 By: tim_one Comment: Assigned to Guido because, as Vlad says, he needs to Prounounce on the idea. Guido, the point here is to provide a single implementation to replace all the repeated and inconsistent functions and macros that modules are defining today for use in their init functions. Was discussed on Python-Dev and was well-received there. Andrew, I dislike the name PyModule_AddConstantLong, because that Python ints *happen* to be C longs should be an implementation detail. Since the function is actually adding a Python int, I'm afraid I like PyModule_AddConstantInt better. Oh, yuck. Ah! PyModule_AddConstantPyInt. ------------------------------------------------------- Date: 2000-Aug-21 17:46 By: gvanrossum Comment: I like the idea fine, but don't think it's important enough to rush it into 2.0. Anyway it needs docs for api.tex. AddConstantPyInt is a bad name becase "PyInt" suggests that the argument is a Python int object, not a C int. Suggestion: PyModule_AddIntConstant and PyModule_AddStringConstant. I'm a bit worried by the implied DECREF in PyModule_AddObject -- this should better go into the other two, or the name should be changed, maybe to _AddNewObject. ------------------------------------------------------- Date: 2000-Sep-15 09:41 By: gvanrossum Comment: Andrew, this was revived. Can you address the comments? I'm not against adding this to 2.0b2, although there are undoubtedly more important things to do. ------------------------------------------------------- Date: 2000-Sep-21 23:17 By: fdrake Comment: Revised version of the patch that addess the concerns noted, adds API documentation. Andrew, please review. ------------------------------------------------------- Date: 2000-Sep-22 12:13 By: fdrake Comment: Guido, Andrew is appearantly too busy to review this. Can you take a look at it? Thanks! ------------------------------------------------------- Date: 2000-Sep-22 20:26 By: fdrake Comment: Andrew & Guido both indicated that the patch was good, so I've applied and closed it. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101233&group_id=5470 From noreply@sourceforge.net Sat Sep 23 05:06:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 22 Sep 2000 21:06:03 -0700 Subject: [Patches] [Patch #101612] Prevent recursion limit when using ".*?xxx" Message-ID: <200009230406.VAA22975@delerium.i.sourceforge.net> Patch #101612 has been updated. Project: Category: Modules Status: Open Summary: Prevent recursion limit when using ".*?xxx" ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101612&group_id=5470 From noreply@sourceforge.net Sat Sep 23 05:12:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 22 Sep 2000 21:12:53 -0700 Subject: [Patches] [Patch #101612] Prevent recursion limit when using ".*?xxx" Message-ID: <200009230412.VAA23155@delerium.i.sourceforge.net> Patch #101612 has been updated. Project: Category: Modules Status: Open Summary: Prevent recursion limit when using ".*?xxx" Follow-Ups: Date: 2000-Sep-22 21:12 By: dgallion Comment: This pattern fails with sre: >>> re.match("(?s){.*?}","{"+' '*17000+"}") Traceback (most recent call last): File "", line 1, in ? File "E:\pythonWinCVS\python\dist\src\lib\sre.py", line 44, in match return _compile(pattern, flags).match(string) RuntimeError: maximum recursion limit exceeded The same pattern with even a much larger search buffer works fine on 1.52 This patch optimizes the case ".*?" and avoids the recursion limit. After the patch: >>> import re >>> re.findall('ab.*?bc', 'abababbc') ['abababbc'] >>> re.findall('ab??bc', 'abababbc') ['abbc'] >>> re.sub("(?s){.*?}","","{"+' '*19047+"}") '' >>> re.match("(?s){.*?}","{"+' '*16048+"}") >>> import test.test_re Running tests on re.search and re.match Running tests on re.sub Running tests on symbolic references Running tests on re.subn Running tests on re.split Running tests on re.findall Running tests on re.match Running tests on re.escape Pickling a RegexObject instance Test engine limitations maximum recursion limit exceeded Running re_tests test suite >>> ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101612&group_id=5470 From noreply@sourceforge.net Sat Sep 23 05:12:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 22 Sep 2000 21:12:52 -0700 Subject: [Patches] [Patch #101612] Prevent recursion limit when using ".*?xxx" Message-ID: <200009230412.VAA23152@delerium.i.sourceforge.net> Patch #101612 has been updated. Project: Category: Modules Status: Open Summary: Prevent recursion limit when using ".*?xxx" Follow-Ups: Date: 2000-Sep-22 21:12 By: dgallion Comment: This pattern fails with sre: >>> re.match("(?s){.*?}","{"+' '*17000+"}") Traceback (most recent call last): File "", line 1, in ? File "E:\pythonWinCVS\python\dist\src\lib\sre.py", line 44, in match return _compile(pattern, flags).match(string) RuntimeError: maximum recursion limit exceeded The same pattern with even a much larger search buffer works fine on 1.52 This patch optimizes the case ".*?" and avoids the recursion limit. After the patch: >>> import re >>> re.findall('ab.*?bc', 'abababbc') ['abababbc'] >>> re.findall('ab??bc', 'abababbc') ['abbc'] >>> re.sub("(?s){.*?}","","{"+' '*19047+"}") '' >>> re.match("(?s){.*?}","{"+' '*16048+"}") >>> import test.test_re Running tests on re.search and re.match Running tests on re.sub Running tests on symbolic references Running tests on re.subn Running tests on re.split Running tests on re.findall Running tests on re.match Running tests on re.escape Pickling a RegexObject instance Test engine limitations maximum recursion limit exceeded Running re_tests test suite >>> ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101612&group_id=5470 From noreply@sourceforge.net Sat Sep 23 05:23:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 22 Sep 2000 21:23:43 -0700 Subject: [Patches] [Patch #101612] Prevent recursion limit when using ".*?xxx" Message-ID: <200009230423.VAA31646@bush.i.sourceforge.net> Patch #101612 has been updated. Project: Category: Modules Status: Open Summary: Prevent recursion limit when using ".*?xxx" Follow-Ups: Date: 2000-Sep-22 21:12 By: dgallion Comment: This pattern fails with sre: >>> re.match("(?s){.*?}","{"+' '*17000+"}") Traceback (most recent call last): File "", line 1, in ? File "E:\pythonWinCVS\python\dist\src\lib\sre.py", line 44, in match return _compile(pattern, flags).match(string) RuntimeError: maximum recursion limit exceeded The same pattern with even a much larger search buffer works fine on 1.52 This patch optimizes the case ".*?" and avoids the recursion limit. After the patch: >>> import re >>> re.findall('ab.*?bc', 'abababbc') ['abababbc'] >>> re.findall('ab??bc', 'abababbc') ['abbc'] >>> re.sub("(?s){.*?}","","{"+' '*19047+"}") '' >>> re.match("(?s){.*?}","{"+' '*16048+"}") >>> import test.test_re Running tests on re.search and re.match Running tests on re.sub Running tests on symbolic references Running tests on re.subn Running tests on re.split Running tests on re.findall Running tests on re.match Running tests on re.escape Pickling a RegexObject instance Test engine limitations maximum recursion limit exceeded Running re_tests test suite >>> ------------------------------------------------------- Date: 2000-Sep-22 21:23 By: tim_one Comment: Assigned to Fredrik. dgallion, please resubmit a context diff. Straight diffs aren't accepted (they're too brittle). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101612&group_id=5470 From noreply@sourceforge.net Sat Sep 23 07:50:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 22 Sep 2000 23:50:32 -0700 Subject: [Patches] [Patch #101612] Prevent recursion limit when using ".*?xxx" Message-ID: <200009230650.XAA03752@bush.i.sourceforge.net> Patch #101612 has been updated. Project: Category: Modules Status: Open Summary: Prevent recursion limit when using ".*?xxx" Follow-Ups: Date: 2000-Sep-22 21:12 By: dgallion Comment: This pattern fails with sre: >>> re.match("(?s){.*?}","{"+' '*17000+"}") Traceback (most recent call last): File "", line 1, in ? File "E:\pythonWinCVS\python\dist\src\lib\sre.py", line 44, in match return _compile(pattern, flags).match(string) RuntimeError: maximum recursion limit exceeded The same pattern with even a much larger search buffer works fine on 1.52 This patch optimizes the case ".*?" and avoids the recursion limit. After the patch: >>> import re >>> re.findall('ab.*?bc', 'abababbc') ['abababbc'] >>> re.findall('ab??bc', 'abababbc') ['abbc'] >>> re.sub("(?s){.*?}","","{"+' '*19047+"}") '' >>> re.match("(?s){.*?}","{"+' '*16048+"}") >>> import test.test_re Running tests on re.search and re.match Running tests on re.sub Running tests on symbolic references Running tests on re.subn Running tests on re.split Running tests on re.findall Running tests on re.match Running tests on re.escape Pickling a RegexObject instance Test engine limitations maximum recursion limit exceeded Running re_tests test suite >>> ------------------------------------------------------- Date: 2000-Sep-22 21:23 By: tim_one Comment: Assigned to Fredrik. dgallion, please resubmit a context diff. Straight diffs aren't accepted (they're too brittle). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101612&group_id=5470 From noreply@sourceforge.net Sun Sep 24 05:10:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 23 Sep 2000 21:10:05 -0700 Subject: [Patches] [Patch #100899] a smaller unicode name database Message-ID: <200009240410.VAA14156@bush.i.sourceforge.net> Patch #100899 has been updated. Project: Category: None Status: Postponed Summary: a smaller unicode name database Follow-Ups: Date: 2000-Jul-15 15:43 By: effbot Comment: duh. it's too large for sourceforge. if you want to play with it, get it from: http://w1.132.telia.com/~u13208596/uninames-patch.txt ------------------------------------------------------- Date: 2000-Aug-03 11:59 By: lemburg Comment: How is the work on this patch coming along ? Will it be ready for 2.0 ? ------------------------------------------------------- Date: 2000-Aug-15 10:42 By: tim_one Comment: /F or MAL, what's going on with this? MAL, did you look at the patch? /F, do you feel it's done? ------------------------------------------------------- Date: 2000-Aug-23 11:39 By: tim_one Comment: Assigned back to /F because he agrees the ball bounced back into his court: [/F, in Python-Dev mail] mal has reviewed the patch, and is waiting for an update from me. ------------------------------------------------------- Date: 2000-Aug-24 04:37 By: lemburg Comment: I'd rather see this patch postponed. Reason: We're not in a hury here -- better get this done right than to quickly throw together a set of patches without some more extensive testing. Comment for future reference: --------------------- Note that I would also like to unify the different Unicode databases (ctype DBs, Unicode DB and Unicode name DB) into one single unicodedb access module which will be written in Python. The sibling C modules can then be loaded dynamically and in a lazy fashion. This will result in an implementation which should be much easier to maintain than the current (2.0) setup. ------------------------------------------------------- Date: 2000-Aug-28 11:55 By: effbot Comment: postponed, for now. I'm still working on the full unidb package, and will reopen this patch again when I've fixed the other things that needs to be fixed before 2.0b1. ------------------------------------------------------- Date: 2000-Sep-23 21:10 By: tim_one Comment: Changed status to Postponed, to match the last thing that was said about it (a month ago). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100899&group_id=5470 From noreply@sourceforge.net Sun Sep 24 13:56:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Sep 2000 05:56:02 -0700 Subject: [Patches] [Patch #101630] adds back the InputSource object Message-ID: <200009241256.FAA00415@bush.i.sourceforge.net> Patch #101630 has been updated. Project: Category: XML Status: Open Summary: adds back the InputSource object ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101630&group_id=5470 From noreply@sourceforge.net Sun Sep 24 13:58:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Sep 2000 05:58:56 -0700 Subject: [Patches] [Patch #101630] adds back the InputSource object Message-ID: <200009241258.FAA00551@bush.i.sourceforge.net> Patch #101630 has been updated. Project: Category: XML Status: Open Summary: adds back the InputSource object Follow-Ups: Date: 2000-Sep-24 05:58 By: larsga Comment: The rationale for this change is that it is mentioned by lots of doco strings in the current source (and also by some of the source). It is also needed for proper EntityResolver support and is also useful in its own right. This patch has been tested and test cases for it added to test_sax.py ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101630&group_id=5470 From noreply@sourceforge.net Sun Sep 24 14:05:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Sep 2000 06:05:44 -0700 Subject: [Patches] [Patch #101631] adds back EntityResolver and DTDHandler Message-ID: <200009241305.GAA00770@bush.i.sourceforge.net> Patch #101631 has been updated. Project: Category: XML Status: Open Summary: adds back EntityResolver and DTDHandler ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101631&group_id=5470 From noreply@sourceforge.net Sun Sep 24 14:10:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Sep 2000 06:10:52 -0700 Subject: [Patches] [Patch #101631] adds back EntityResolver and DTDHandler Message-ID: <200009241310.GAA00948@bush.i.sourceforge.net> Patch #101631 has been updated. Project: Category: XML Status: Open Summary: adds back EntityResolver and DTDHandler Follow-Ups: Date: 2000-Sep-24 06:10 By: larsga Comment: This patch depends on 101630. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101631&group_id=5470 From noreply@sourceforge.net Sun Sep 24 15:18:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Sep 2000 07:18:09 -0700 Subject: [Patches] [Patch #101632] extends 101573 with attribute support Message-ID: <200009241418.HAA03087@bush.i.sourceforge.net> Patch #101632 has been updated. Project: Category: XML Status: Open Summary: extends 101573 with attribute support ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101632&group_id=5470 From noreply@sourceforge.net Sun Sep 24 15:34:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Sep 2000 07:34:00 -0700 Subject: [Patches] [Patch #101573] a first start on updating expatreader.py Message-ID: <200009241434.HAA27903@delerium.i.sourceforge.net> Patch #101573 has been updated. Project: Category: XML Status: Open Summary: a first start on updating expatreader.py Follow-Ups: Date: 2000-Sep-21 10:03 By: fdrake Comment: I can't accept this until corresponding patches are made elsewhere in the xml package. The DOM implementation in particular requires updating, or the regression test will fail. I've sent mail to Paul Prescod and Lars Garshol about this. They have a short timeframe if they want to avoid me doing to work and forcing compliance with the coding standard. ;-) ------------------------------------------------------- Date: 2000-Sep-24 07:34 By: larsga Comment: Added fixes to the minidom package so that the regression test no longer fails. As far as I know, no further changes are needed. Now uses context diff. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101573&group_id=5470 From noreply@sourceforge.net Sun Sep 24 15:55:20 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Sep 2000 07:55:20 -0700 Subject: [Patches] [Patch #101630] adds back the InputSource object Message-ID: <200009241455.HAA28644@delerium.i.sourceforge.net> Patch #101630 has been updated. Project: Category: XML Status: Open Summary: adds back the InputSource object Follow-Ups: Date: 2000-Sep-24 05:58 By: larsga Comment: The rationale for this change is that it is mentioned by lots of doco strings in the current source (and also by some of the source). It is also needed for proper EntityResolver support and is also useful in its own right. This patch has been tested and test cases for it added to test_sax.py ------------------------------------------------------- Date: 2000-Sep-24 07:55 By: larsga Comment: Forgot parseString in __init__.py first time around. Added it to the patch now. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101630&group_id=5470 From noreply@sourceforge.net Sun Sep 24 16:41:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Sep 2000 08:41:22 -0700 Subject: [Patches] [Patch #101630] adds back the InputSource object Message-ID: <200009241541.IAA30340@delerium.i.sourceforge.net> Patch #101630 has been updated. Project: Category: XML Status: Open Summary: adds back the InputSource object Follow-Ups: Date: 2000-Sep-24 05:58 By: larsga Comment: The rationale for this change is that it is mentioned by lots of doco strings in the current source (and also by some of the source). It is also needed for proper EntityResolver support and is also useful in its own right. This patch has been tested and test cases for it added to test_sax.py ------------------------------------------------------- Date: 2000-Sep-24 07:55 By: larsga Comment: Forgot parseString in __init__.py first time around. Added it to the patch now. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101630&group_id=5470 From noreply@sourceforge.net Sun Sep 24 16:41:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Sep 2000 08:41:22 -0700 Subject: [Patches] [Patch #101632] extends 101573 with attribute support Message-ID: <200009241541.IAA30346@delerium.i.sourceforge.net> Patch #101632 has been updated. Project: Category: XML Status: Open Summary: extends 101573 with attribute support ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101632&group_id=5470 From noreply@sourceforge.net Sun Sep 24 16:41:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Sep 2000 08:41:22 -0700 Subject: [Patches] [Patch #101631] adds back EntityResolver and DTDHandler Message-ID: <200009241541.IAA30343@delerium.i.sourceforge.net> Patch #101631 has been updated. Project: Category: XML Status: Open Summary: adds back EntityResolver and DTDHandler Follow-Ups: Date: 2000-Sep-24 06:10 By: larsga Comment: This patch depends on 101630. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101631&group_id=5470 From noreply@sourceforge.net Sun Sep 24 17:02:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Sep 2000 09:02:45 -0700 Subject: [Patches] [Patch #101630] adds back the InputSource object Message-ID: <200009241602.JAA06959@bush.i.sourceforge.net> Patch #101630 has been updated. Project: Category: XML Status: Accepted Summary: adds back the InputSource object Follow-Ups: Date: 2000-Sep-24 05:58 By: larsga Comment: The rationale for this change is that it is mentioned by lots of doco strings in the current source (and also by some of the source). It is also needed for proper EntityResolver support and is also useful in its own right. This patch has been tested and test cases for it added to test_sax.py ------------------------------------------------------- Date: 2000-Sep-24 07:55 By: larsga Comment: Forgot parseString in __init__.py first time around. Added it to the patch now. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101630&group_id=5470 From noreply@sourceforge.net Sun Sep 24 17:04:51 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Sep 2000 09:04:51 -0700 Subject: [Patches] [Patch #101631] adds back EntityResolver and DTDHandler Message-ID: <200009241604.JAA06999@bush.i.sourceforge.net> Patch #101631 has been updated. Project: Category: XML Status: Accepted Summary: adds back EntityResolver and DTDHandler Follow-Ups: Date: 2000-Sep-24 06:10 By: larsga Comment: This patch depends on 101630. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101631&group_id=5470 From noreply@sourceforge.net Sun Sep 24 17:07:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Sep 2000 09:07:05 -0700 Subject: [Patches] [Patch #101573] a first start on updating expatreader.py Message-ID: <200009241607.JAA07125@bush.i.sourceforge.net> Patch #101573 has been updated. Project: Category: XML Status: Accepted Summary: a first start on updating expatreader.py Follow-Ups: Date: 2000-Sep-21 10:03 By: fdrake Comment: I can't accept this until corresponding patches are made elsewhere in the xml package. The DOM implementation in particular requires updating, or the regression test will fail. I've sent mail to Paul Prescod and Lars Garshol about this. They have a short timeframe if they want to avoid me doing to work and forcing compliance with the coding standard. ;-) ------------------------------------------------------- Date: 2000-Sep-24 07:34 By: larsga Comment: Added fixes to the minidom package so that the regression test no longer fails. As far as I know, no further changes are needed. Now uses context diff. ------------------------------------------------------- Date: 2000-Sep-24 09:07 By: fdrake Comment: This may need to be updated based on my changes to expatreader, but it shouldn't be a big problem to do so. If you don't get a chance to do that, I can work on it tonight I think. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101573&group_id=5470 From noreply@sourceforge.net Sun Sep 24 17:08:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Sep 2000 09:08:48 -0700 Subject: [Patches] [Patch #101632] extends 101573 with attribute support Message-ID: <200009241608.JAA07143@bush.i.sourceforge.net> Patch #101632 has been updated. Project: Category: XML Status: Accepted Summary: extends 101573 with attribute support ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101632&group_id=5470 From noreply@sourceforge.net Sun Sep 24 19:32:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Sep 2000 11:32:54 -0700 Subject: [Patches] [Patch #101573] a first start on updating expatreader.py Message-ID: <200009241832.LAA12245@bush.i.sourceforge.net> Patch #101573 has been updated. Project: Category: XML Status: Closed Summary: a first start on updating expatreader.py Follow-Ups: Date: 2000-Sep-21 10:03 By: fdrake Comment: I can't accept this until corresponding patches are made elsewhere in the xml package. The DOM implementation in particular requires updating, or the regression test will fail. I've sent mail to Paul Prescod and Lars Garshol about this. They have a short timeframe if they want to avoid me doing to work and forcing compliance with the coding standard. ;-) ------------------------------------------------------- Date: 2000-Sep-24 07:34 By: larsga Comment: Added fixes to the minidom package so that the regression test no longer fails. As far as I know, no further changes are needed. Now uses context diff. ------------------------------------------------------- Date: 2000-Sep-24 09:07 By: fdrake Comment: This may need to be updated based on my changes to expatreader, but it shouldn't be a big problem to do so. If you don't get a chance to do that, I can work on it tonight I think. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101573&group_id=5470 From noreply@sourceforge.net Sun Sep 24 19:40:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Sep 2000 11:40:24 -0700 Subject: [Patches] [Patch #101632] extends 101573 with attribute support Message-ID: <200009241840.LAA12500@bush.i.sourceforge.net> Patch #101632 has been updated. Project: Category: XML Status: Closed Summary: extends 101573 with attribute support ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101632&group_id=5470 From noreply@sourceforge.net Sun Sep 24 19:55:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Sep 2000 11:55:01 -0700 Subject: [Patches] [Patch #101630] adds back the InputSource object Message-ID: <200009241855.LAA04719@delerium.i.sourceforge.net> Patch #101630 has been updated. Project: Category: XML Status: Closed Summary: adds back the InputSource object Follow-Ups: Date: 2000-Sep-24 05:58 By: larsga Comment: The rationale for this change is that it is mentioned by lots of doco strings in the current source (and also by some of the source). It is also needed for proper EntityResolver support and is also useful in its own right. This patch has been tested and test cases for it added to test_sax.py ------------------------------------------------------- Date: 2000-Sep-24 07:55 By: larsga Comment: Forgot parseString in __init__.py first time around. Added it to the patch now. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101630&group_id=5470 From noreply@sourceforge.net Sun Sep 24 21:24:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Sep 2000 13:24:21 -0700 Subject: [Patches] [Patch #101634] SAX: Fix parse and parseString, support parsing of open file Message-ID: <200009242024.NAA07838@delerium.i.sourceforge.net> Patch #101634 has been updated. Project: Category: library Status: Open Summary: SAX: Fix parse and parseString, support parsing of open file ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101634&group_id=5470 From noreply@sourceforge.net Sun Sep 24 21:26:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Sep 2000 13:26:52 -0700 Subject: [Patches] [Patch #101631] adds back EntityResolver and DTDHandler Message-ID: <200009242026.NAA16486@bush.i.sourceforge.net> Patch #101631 has been updated. Project: Category: XML Status: Closed Summary: adds back EntityResolver and DTDHandler Follow-Ups: Date: 2000-Sep-24 06:10 By: larsga Comment: This patch depends on 101630. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101631&group_id=5470 From noreply@sourceforge.net Sun Sep 24 21:42:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Sep 2000 13:42:19 -0700 Subject: [Patches] [Patch #101635] adds ExternaltEntityParserCreate method Message-ID: <200009242042.NAA17077@bush.i.sourceforge.net> Patch #101635 has been updated. Project: Category: XML Status: Open Summary: adds ExternaltEntityParserCreate method ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101635&group_id=5470 From noreply@sourceforge.net Sun Sep 24 22:21:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Sep 2000 14:21:22 -0700 Subject: [Patches] [Patch #101634] SAX: Fix parse and parseString, support parsing of open file Message-ID: <200009242121.OAA09815@delerium.i.sourceforge.net> Patch #101634 has been updated. Project: Category: library Status: Accepted Summary: SAX: Fix parse and parseString, support parsing of open file ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101634&group_id=5470 From noreply@sourceforge.net Sun Sep 24 22:22:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Sep 2000 14:22:18 -0700 Subject: [Patches] [Patch #101635] adds ExternaltEntityParserCreate method Message-ID: <200009242122.OAA09916@delerium.i.sourceforge.net> Patch #101635 has been updated. Project: Category: XML Status: Accepted Summary: adds ExternaltEntityParserCreate method ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101635&group_id=5470 From noreply@sourceforge.net Sun Sep 24 22:31:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Sep 2000 14:31:45 -0700 Subject: [Patches] [Patch #101634] SAX: Fix parse and parseString, support parsing of open file Message-ID: <200009242131.OAA10286@delerium.i.sourceforge.net> Patch #101634 has been updated. Project: Category: library Status: Closed Summary: SAX: Fix parse and parseString, support parsing of open file Follow-Ups: Date: 2000-Sep-24 14:31 By: loewis Comment: I have applied this patch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101634&group_id=5470 From noreply@sourceforge.net Sun Sep 24 22:32:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Sep 2000 14:32:21 -0700 Subject: [Patches] [Patch #101636] pulldom: Use updated SAX2 *NS functions Message-ID: <200009242132.OAA10293@delerium.i.sourceforge.net> Patch #101636 has been updated. Project: Category: library Status: Open Summary: pulldom: Use updated SAX2 *NS functions ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101636&group_id=5470 From noreply@sourceforge.net Sun Sep 24 22:39:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Sep 2000 14:39:49 -0700 Subject: [Patches] [Patch #101636] pulldom: Use updated SAX2 *NS functions Message-ID: <200009242139.OAA19080@bush.i.sourceforge.net> Patch #101636 has been updated. Project: Category: library Status: Open Summary: pulldom: Use updated SAX2 *NS functions Follow-Ups: Date: 2000-Sep-24 14:39 By: fdrake Comment: Is the inherited non-NS version of startElement() sufficient? Your "def __init__" line added the spaces back around the "self"; please remove for conformance with the Python style guide. If the startElement() really good for non-NS operation, make the above change and check it in. Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101636&group_id=5470 From noreply@sourceforge.net Sun Sep 24 22:49:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Sep 2000 14:49:43 -0700 Subject: [Patches] [Patch #101636] pulldom: Use updated SAX2 *NS functions Message-ID: <200009242149.OAA10908@delerium.i.sourceforge.net> Patch #101636 has been updated. Project: Category: library Status: Open Summary: pulldom: Use updated SAX2 *NS functions Follow-Ups: Date: 2000-Sep-24 14:39 By: fdrake Comment: Is the inherited non-NS version of startElement() sufficient? Your "def __init__" line added the spaces back around the "self"; please remove for conformance with the Python style guide. If the startElement() really good for non-NS operation, make the above change and check it in. Thanks! ------------------------------------------------------- Date: 2000-Sep-24 14:49 By: loewis Comment: A parser with feature_namespaces activated will never call startElement, only startElementNS. Since pulldom.PullDOM.startElementNS will invoke createElementNS only if the tag name is namespace-scoped, this callback will also work for documents without callbacks. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101636&group_id=5470 From noreply@sourceforge.net Sun Sep 24 22:55:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Sep 2000 14:55:43 -0700 Subject: [Patches] [Patch #101636] pulldom: Use updated SAX2 *NS functions Message-ID: <200009242155.OAA11115@delerium.i.sourceforge.net> Patch #101636 has been updated. Project: Category: library Status: Closed Summary: pulldom: Use updated SAX2 *NS functions Follow-Ups: Date: 2000-Sep-24 14:39 By: fdrake Comment: Is the inherited non-NS version of startElement() sufficient? Your "def __init__" line added the spaces back around the "self"; please remove for conformance with the Python style guide. If the startElement() really good for non-NS operation, make the above change and check it in. Thanks! ------------------------------------------------------- Date: 2000-Sep-24 14:49 By: loewis Comment: A parser with feature_namespaces activated will never call startElement, only startElementNS. Since pulldom.PullDOM.startElementNS will invoke createElementNS only if the tag name is namespace-scoped, this callback will also work for documents without callbacks. ------------------------------------------------------- Date: 2000-Sep-24 14:55 By: loewis Comment: ... documents without namespaces. Patch applied in pulldom.py 1.7. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101636&group_id=5470 From noreply@sourceforge.net Mon Sep 25 08:09:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 00:09:04 -0700 Subject: [Patches] [Patch #101635] adds ExternaltEntityParserCreate method Message-ID: <200009250709.AAA05613@bush.i.sourceforge.net> Patch #101635 has been updated. Project: Category: XML Status: Closed Summary: adds ExternaltEntityParserCreate method ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101635&group_id=5470 From noreply@sourceforge.net Mon Sep 25 17:34:51 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 09:34:51 -0700 Subject: [Patches] [Patch #101647] adds SSL server socket support to socketmodule.c Message-ID: <200009251634.JAA26788@bush.i.sourceforge.net> Patch #101647 has been updated. Project: Category: Modules Status: Open Summary: adds SSL server socket support to socketmodule.c ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101647&group_id=5470 From noreply@sourceforge.net Mon Sep 25 17:41:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 09:41:46 -0700 Subject: [Patches] [Patch #101647] adds SSL server socket support to socketmodule.c Message-ID: <200009251641.JAA27053@bush.i.sourceforge.net> Patch #101647 has been updated. Project: Category: Modules Status: Postponed Summary: adds SSL server socket support to socketmodule.c Follow-Ups: Date: 2000-Sep-25 09:41 By: jhylton Comment: too late for 2.0 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101647&group_id=5470 From noreply@sourceforge.net Mon Sep 25 17:42:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 09:42:17 -0700 Subject: [Patches] [Patch #100803] puremodule: ANSI-fication (UNTESTED!) Message-ID: <200009251642.JAA27056@bush.i.sourceforge.net> Patch #100803 has been updated. Project: Category: None Status: Postponed Summary: puremodule: ANSI-fication (UNTESTED!) Follow-Ups: Date: 2000-Jul-10 10:16 By: nowonder Comment: cannot test this, maybe Barry can ------------------------------------------------------- Date: 2000-Jul-31 01:46 By: nowonder Comment: should I just check it in? Did you get around to review it? ------------------------------------------------------- Date: 2000-Jul-31 09:30 By: bwarsaw Comment: There's one typo in nowonder's patch. Here's a fixed version of the patch (unified). This compiles but doesn't link. I can't tell if this is caused by a problem with the purify stub libraries. Meta note: because this is a commercial product which it seems no one has access to anymore, should we continue to support it in the standard distribution? ------------------------------------------------------- Date: 2000-Jul-31 10:30 By: gvanrossum Comment: Since no-one can test this, let's be conservative and not check it in. There's no absolute requirement to move *everything* to ANSI. Since we know the old version worked, we should leave it alone. I vote to keep this in the distribution -- maybe someone else can use it. If someone else can confirm that it in fact works (or make it work) I'd be happy to accept the patch at that point. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=100803&group_id=5470 From noreply@sourceforge.net Mon Sep 25 17:42:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 09:42:44 -0700 Subject: [Patches] [Patch #101485] Patch to test sendmail virtual domain gid's for bug #114235 Message-ID: <200009251642.JAA27096@bush.i.sourceforge.net> Patch #101485 has been updated. Project: Category: None Status: Postponed Summary: Patch to test sendmail virtual domain gid's for bug #114235 Follow-Ups: Date: 2000-Sep-12 15:22 By: bwarsaw Comment: See SF bug #114235 for what this program tests. This patch (and the bug) really have nothing to do with Python, I believe. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101485&group_id=5470 From noreply@sourceforge.net Mon Sep 25 17:42:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 09:42:43 -0700 Subject: [Patches] [Patch #101416] coax _sre.c into using Py_GetRecursionLimit() Message-ID: <200009251642.JAA27093@bush.i.sourceforge.net> Patch #101416 has been updated. Project: Category: Modules Status: Postponed Summary: coax _sre.c into using Py_GetRecursionLimit() Follow-Ups: Date: 2000-Sep-04 09:02 By: montanaro Comment: seems obvious that Fredrik should be the one to handle this... ------------------------------------------------------- Date: 2000-Sep-15 07:21 By: fdrake Comment: The declaration of rlimit should be wrapped in #ifdef USE_RECURSION_LIMIT / #endif, since it isn't used otherwise. ------------------------------------------------------- Date: 2000-Sep-15 08:26 By: montanaro Comment: thanks - new version adds the appropriate ifdef ------------------------------------------------------- Date: 2000-Sep-22 05:54 By: fdrake Comment: Fredrik, are there problems with this patch? Does it not make sense? Please take action on this. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101416&group_id=5470 From noreply@sourceforge.net Mon Sep 25 17:42:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 09:42:44 -0700 Subject: [Patches] [Patch #101606] threads and __del__ Message-ID: <200009251642.JAA27099@bush.i.sourceforge.net> Patch #101606 has been updated. Project: Category: core (C code) Status: Postponed Summary: threads and __del__ Follow-Ups: Date: 2000-Sep-22 08:06 By: gvanrossum Comment: Works fine for me. Assigned to Tim for review since he's the race condition czar. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101606&group_id=5470 From noreply@sourceforge.net Mon Sep 25 17:42:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 09:42:45 -0700 Subject: [Patches] [Patch #101612] Prevent recursion limit when using ".*?xxx" Message-ID: <200009251642.JAA27102@bush.i.sourceforge.net> Patch #101612 has been updated. Project: Category: Modules Status: Postponed Summary: Prevent recursion limit when using ".*?xxx" Follow-Ups: Date: 2000-Sep-22 21:12 By: dgallion Comment: This pattern fails with sre: >>> re.match("(?s){.*?}","{"+' '*17000+"}") Traceback (most recent call last): File "", line 1, in ? File "E:\pythonWinCVS\python\dist\src\lib\sre.py", line 44, in match return _compile(pattern, flags).match(string) RuntimeError: maximum recursion limit exceeded The same pattern with even a much larger search buffer works fine on 1.52 This patch optimizes the case ".*?" and avoids the recursion limit. After the patch: >>> import re >>> re.findall('ab.*?bc', 'abababbc') ['abababbc'] >>> re.findall('ab??bc', 'abababbc') ['abbc'] >>> re.sub("(?s){.*?}","","{"+' '*19047+"}") '' >>> re.match("(?s){.*?}","{"+' '*16048+"}") >>> import test.test_re Running tests on re.search and re.match Running tests on re.sub Running tests on symbolic references Running tests on re.subn Running tests on re.split Running tests on re.findall Running tests on re.match Running tests on re.escape Pickling a RegexObject instance Test engine limitations maximum recursion limit exceeded Running re_tests test suite >>> ------------------------------------------------------- Date: 2000-Sep-22 21:23 By: tim_one Comment: Assigned to Fredrik. dgallion, please resubmit a context diff. Straight diffs aren't accepted (they're too brittle). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101612&group_id=5470 From noreply@sourceforge.net Mon Sep 25 17:50:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 09:50:22 -0700 Subject: [Patches] [Patch #101416] coax _sre.c into using Py_GetRecursionLimit() Message-ID: <200009251650.JAA27430@bush.i.sourceforge.net> Patch #101416 has been updated. Project: Category: Modules Status: Postponed Summary: coax _sre.c into using Py_GetRecursionLimit() Follow-Ups: Date: 2000-Sep-04 09:02 By: montanaro Comment: seems obvious that Fredrik should be the one to handle this... ------------------------------------------------------- Date: 2000-Sep-15 07:21 By: fdrake Comment: The declaration of rlimit should be wrapped in #ifdef USE_RECURSION_LIMIT / #endif, since it isn't used otherwise. ------------------------------------------------------- Date: 2000-Sep-15 08:26 By: montanaro Comment: thanks - new version adds the appropriate ifdef ------------------------------------------------------- Date: 2000-Sep-22 05:54 By: fdrake Comment: Fredrik, are there problems with this patch? Does it not make sense? Please take action on this. ------------------------------------------------------- Date: 2000-Sep-25 09:50 By: montanaro Comment: Postponing this is okay with me, but I am almost certain the new _sre module is going to cause problems for nasty regular expressions that the 1.5.2 re module could handle. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101416&group_id=5470 From jeremy@beopen.com Mon Sep 25 17:58:57 2000 From: jeremy@beopen.com (Jeremy Hylton) Date: Mon, 25 Sep 2000 12:58:57 -0400 (EDT) Subject: [Patches] [Patch #101416] coax _sre.c into using Py_GetRecursionLimit() In-Reply-To: <200009251650.JAA27430@bush.i.sourceforge.net> References: <200009251650.JAA27430@bush.i.sourceforge.net> Message-ID: <14799.33873.26472.721668@bitdiddle.concentric.net> Unfortunately, it's too late to get this fixed for 2.0b2. If it is a bug fix, we can re-open it for 2.0 final. Jeremy From Fredrik Lundh" Message-ID: <00ec01c02713$473b3ba0$766940d5@hagrid> skip wrote: > Postponing this is okay with me, but I am almost certain > the new _sre module is going to cause problems for > nasty regular expressions that the 1.5.2 re module > could handle. hopefully, "postpone" means "postpone beyond 2.0b2", not beyond 2.0 final. From noreply@sourceforge.net Mon Sep 25 20:41:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 12:41:10 -0700 Subject: [Patches] [Patch #101651] Gracefully detect usage of old extension module Message-ID: <200009251941.MAA25934@delerium.i.sourceforge.net> Patch #101651 has been updated. Project: Category: Windows Status: Open Summary: Gracefully detect usage of old extension module ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101651&group_id=5470 From noreply@sourceforge.net Mon Sep 25 20:49:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 12:49:15 -0700 Subject: [Patches] [Patch #101651] Gracefully detect usage of old extension module Message-ID: <200009251949.MAA26331@delerium.i.sourceforge.net> Patch #101651 has been updated. Project: Category: Windows Status: Open Summary: Gracefully detect usage of old extension module Follow-Ups: Date: 2000-Sep-25 12:49 By: loewis Comment: Also see commentary inside the patch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101651&group_id=5470 From noreply@sourceforge.net Mon Sep 25 21:25:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 13:25:19 -0700 Subject: [Patches] [Patch #101652] unidb-based unicodectype.c replacement Message-ID: <200009252025.NAA27750@delerium.i.sourceforge.net> Patch #101652 has been updated. Project: Category: core (C code) Status: Open Summary: unidb-based unicodectype.c replacement ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101652&group_id=5470 From noreply@sourceforge.net Mon Sep 25 21:28:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 13:28:13 -0700 Subject: [Patches] [Patch #101652] unidb-based unicodectype.c replacement Message-ID: <200009252028.NAA27861@delerium.i.sourceforge.net> Patch #101652 has been updated. Project: Category: core (C code) Status: Open Summary: unidb-based unicodectype.c replacement Follow-Ups: Date: 2000-Sep-25 13:28 By: none Comment: (not a patch -- this is replacing a 450k source file with a 14k source file, and the resulting patch file is too large for sourceforge...) to generate the associated datafile, check out the latest Tools/unicode/makeunicodedata.py ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101652&group_id=5470 From noreply@sourceforge.net Mon Sep 25 21:28:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 13:28:13 -0700 Subject: [Patches] [Patch #101652] unidb-based unicodectype.c replacement Message-ID: <200009252028.NAA27864@delerium.i.sourceforge.net> Patch #101652 has been updated. Project: Category: core (C code) Status: Open Summary: unidb-based unicodectype.c replacement Follow-Ups: Date: 2000-Sep-25 13:28 By: none Comment: (not a patch -- this is replacing a 450k source file with a 14k source file, and the resulting patch file is too large for sourceforge...) to generate the associated datafile, check out the latest Tools/unicode/makeunicodedata.py ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101652&group_id=5470 From noreply@sourceforge.net Mon Sep 25 21:32:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 13:32:52 -0700 Subject: [Patches] [Patch #101653] unidb-based unicodetype.c replacement (part 2) Message-ID: <200009252032.NAA28064@delerium.i.sourceforge.net> Patch #101653 has been updated. Project: Category: core (C code) Status: Open Summary: unidb-based unicodetype.c replacement (part 2) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101653&group_id=5470 From noreply@sourceforge.net Mon Sep 25 22:10:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 14:10:44 -0700 Subject: [Patches] [Patch #101652] unidb-based unicodectype.c replacement Message-ID: <200009252110.OAA29620@delerium.i.sourceforge.net> Patch #101652 has been updated. Project: Category: core (C code) Status: Open Summary: unidb-based unicodectype.c replacement Follow-Ups: Date: 2000-Sep-25 13:28 By: none Comment: (not a patch -- this is replacing a 450k source file with a 14k source file, and the resulting patch file is too large for sourceforge...) to generate the associated datafile, check out the latest Tools/unicode/makeunicodedata.py ------------------------------------------------------- Date: 2000-Sep-25 14:10 By: lemburg Comment: The code looks ok, but I can't really follow the technique you use for the lower/upper mappings: why can't you simply use "const Py_UNICODE" + "return ctype->lower" instead of "unsigned short" and then "return (ch + ctype->lower) & 0xffff" ?! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101652&group_id=5470 From noreply@sourceforge.net Mon Sep 25 22:13:30 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 14:13:30 -0700 Subject: [Patches] [Patch #101653] unidb-based unicodetype.c replacement (part 2) Message-ID: <200009252113.OAA29782@delerium.i.sourceforge.net> Patch #101653 has been updated. Project: Category: core (C code) Status: Open Summary: unidb-based unicodetype.c replacement (part 2) Follow-Ups: Date: 2000-Sep-25 14:13 By: lemburg Comment: Some compilers out there have problems with static arrays which don't specify the number of records in their constructors. Wouldn't it be possible to generate the array bounds in the generation script ? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101653&group_id=5470 From noreply@sourceforge.net Mon Sep 25 22:34:51 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 14:34:51 -0700 Subject: [Patches] [Patch #101653] unidb-based unicodetype.c replacement (part 2) Message-ID: <200009252134.OAA06223@bush.i.sourceforge.net> Patch #101653 has been updated. Project: Category: core (C code) Status: Open Summary: unidb-based unicodetype.c replacement (part 2) Follow-Ups: Date: 2000-Sep-25 14:13 By: lemburg Comment: Some compilers out there have problems with static arrays which don't specify the number of records in their constructors. Wouldn't it be possible to generate the array bounds in the generation script ? ------------------------------------------------------- Date: 2000-Sep-25 14:34 By: twouters Comment: A quick grep shows about 850 static arrays with unspecified length in the current Python source tree. I'm not against adding the length explicitly (can't hurt, after all) but it's probably not worth the trouble if it can't be done easily. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101653&group_id=5470 From noreply@sourceforge.net Mon Sep 25 22:38:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 14:38:06 -0700 Subject: [Patches] [Patch #101394] lookdict optimizations Message-ID: <200009252138.OAA06297@bush.i.sourceforge.net> Patch #101394 has been updated. Project: Category: core (C code) Status: Accepted Summary: lookdict optimizations Follow-Ups: Date: 2000-Sep-03 21:09 By: marangoz Comment: Let's add a comment, although this has been raised on python-dev. This patch proposes a couple of ideas for optimizing & speeding dict lookups -- not all of them need to be applied though. - clear the eventual errors from Object_Compare only on need (this logic needs to be double-checked once again to see whether it really works) - defer variable initializations after the most common return cases - specialize string_compare() for lookdict_string. The test comparing the first char, before calling memcmp(), can be added too. - inline the first item probe in PyDict_GetItem. This saves a func call for the most common case (common to lookdict & lookdict_string). ------------------------------------------------------- Date: 2000-Sep-04 06:45 By: gvanrossum Comment: Quick comments: we should *always* call PyErr_Occurred() after PyObject_Compare() (and PyErr_Clear() if PyErr_Occurred() returned true). PyErr_Compare() really doesn't expect a pending exception coming in and so *not* clearing the error might break the *next* PyErr_Compare() call. (This doesn't happen typically but PyObject_Compare() can execute arbitrary code, some of which might call PyErr_Occurred() without calling PyErr_Clear() first.) ------------------------------------------------------- Date: 2000-Sep-05 06:05 By: none Comment: Correct! But then, aren't the current "else" if(cmp == 0) clauses risky after PyObject_Compare()? An exception may be set in external code while making Object_Compare() to return 0! Perhaps not in Python source, but in buggy extensions. lookdict() will then overlook this "hit". Patch updated, without "else" clauses and with the 1st char check in string_compare_equal(). ------------------------------------------------------- Date: 2000-Sep-05 06:08 By: marangoz Comment: Argh! These Web interfaces strike again - forgot to login. ------------------------------------------------------- Date: 2000-Sep-14 09:26 By: fdrake Comment: Revised patch: Instead of defining a function to do the fast string comparison, use a macro, but let it use the documented string object API (PyString_GET_SIZE(), PyString_AS_STRING()) instead of breaking the encapsulation in the code. This avoids all function calls to do the string compare, except memcmp() (which good compilers can inline anyway). Vladimir, take a look at this; if you're happy, I'm happy, and you can check it in. Thanks! ------------------------------------------------------- Date: 2000-Sep-14 13:51 By: fdrake Comment: Guido, please review (since Vladimir's away). ------------------------------------------------------- Date: 2000-Sep-15 11:18 By: gvanrossum Comment: Accepted. Assuming you've tested this, it looks fine to me. Can you time this a bit? There's one niggling issue: some people think that before you do memcmp() you should manually compare the first character. Others think that's unnecessary (since a good compiler can inline memcmp anyway). (It's also a bit scary if the size is zero.) So please ignore this but keep it in mind for timing experiments. :) ------------------------------------------------------- Date: 2000-Sep-25 14:38 By: twouters Comment: Shouldn't this patch be either postponed or checked in? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101394&group_id=5470 From noreply@sourceforge.net Mon Sep 25 23:03:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 15:03:43 -0700 Subject: [Patches] [Patch #101653] unidb-based unicodetype.c replacement (part 2) Message-ID: <200009252203.PAA31766@delerium.i.sourceforge.net> Patch #101653 has been updated. Project: Category: core (C code) Status: Open Summary: unidb-based unicodetype.c replacement (part 2) Follow-Ups: Date: 2000-Sep-25 14:13 By: lemburg Comment: Some compilers out there have problems with static arrays which don't specify the number of records in their constructors. Wouldn't it be possible to generate the array bounds in the generation script ? ------------------------------------------------------- Date: 2000-Sep-25 14:34 By: twouters Comment: A quick grep shows about 850 static arrays with unspecified length in the current Python source tree. I'm not against adding the length explicitly (can't hurt, after all) but it's probably not worth the trouble if it can't be done easily. ------------------------------------------------------- Date: 2000-Sep-25 15:03 By: tim_one Comment: It's easy for the script to add this. I'd like to see it too, but only mildly -- it's a nice little check on whether all the elements actually got written out. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101653&group_id=5470 From noreply@sourceforge.net Mon Sep 25 23:19:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 15:19:52 -0700 Subject: [Patches] [Patch #101653] unidb-based unicodetype.c replacement (part 2) Message-ID: <200009252219.PAA32651@delerium.i.sourceforge.net> Patch #101653 has been updated. Project: Category: core (C code) Status: Open Summary: unidb-based unicodetype.c replacement (part 2) Follow-Ups: Date: 2000-Sep-25 14:13 By: lemburg Comment: Some compilers out there have problems with static arrays which don't specify the number of records in their constructors. Wouldn't it be possible to generate the array bounds in the generation script ? ------------------------------------------------------- Date: 2000-Sep-25 14:34 By: twouters Comment: A quick grep shows about 850 static arrays with unspecified length in the current Python source tree. I'm not against adding the length explicitly (can't hurt, after all) but it's probably not worth the trouble if it can't be done easily. ------------------------------------------------------- Date: 2000-Sep-25 15:03 By: tim_one Comment: It's easy for the script to add this. I'd like to see it too, but only mildly -- it's a nice little check on whether all the elements actually got written out. ------------------------------------------------------- Date: 2000-Sep-25 15:19 By: lemburg Comment: Something else I noticed when I updated my CVS tree: There's a typo in the filename for the unicodectype table: it should be unicodectype_db.h, not unicodetype_db.h (note the missing "c"). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101653&group_id=5470 From noreply@sourceforge.net Mon Sep 25 23:33:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 15:33:43 -0700 Subject: [Patches] [Patch #101653] unidb-based unicodetype.c replacement (part 2) Message-ID: <200009252233.PAA00752@delerium.i.sourceforge.net> Patch #101653 has been updated. Project: Category: core (C code) Status: Open Summary: unidb-based unicodetype.c replacement (part 2) Follow-Ups: Date: 2000-Sep-25 14:13 By: lemburg Comment: Some compilers out there have problems with static arrays which don't specify the number of records in their constructors. Wouldn't it be possible to generate the array bounds in the generation script ? ------------------------------------------------------- Date: 2000-Sep-25 14:34 By: twouters Comment: A quick grep shows about 850 static arrays with unspecified length in the current Python source tree. I'm not against adding the length explicitly (can't hurt, after all) but it's probably not worth the trouble if it can't be done easily. ------------------------------------------------------- Date: 2000-Sep-25 15:03 By: tim_one Comment: It's easy for the script to add this. I'd like to see it too, but only mildly -- it's a nice little check on whether all the elements actually got written out. ------------------------------------------------------- Date: 2000-Sep-25 15:19 By: lemburg Comment: Something else I noticed when I updated my CVS tree: There's a typo in the filename for the unicodectype table: it should be unicodectype_db.h, not unicodetype_db.h (note the missing "c"). ------------------------------------------------------- Date: 2000-Sep-25 15:33 By: none Comment: the tables are taken from the unidb project, and have the same names: "unicodename_db", "unicodetype_db", and "unicodedata_db". the patch summary contains a real typo, though... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101653&group_id=5470 From noreply@sourceforge.net Mon Sep 25 23:33:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 15:33:43 -0700 Subject: [Patches] [Patch #101653] unidb-based unicodetype.c replacement (part 2) Message-ID: <200009252233.PAA00755@delerium.i.sourceforge.net> Patch #101653 has been updated. Project: Category: core (C code) Status: Open Summary: unidb-based unicodetype.c replacement (part 2) Follow-Ups: Date: 2000-Sep-25 14:13 By: lemburg Comment: Some compilers out there have problems with static arrays which don't specify the number of records in their constructors. Wouldn't it be possible to generate the array bounds in the generation script ? ------------------------------------------------------- Date: 2000-Sep-25 14:34 By: twouters Comment: A quick grep shows about 850 static arrays with unspecified length in the current Python source tree. I'm not against adding the length explicitly (can't hurt, after all) but it's probably not worth the trouble if it can't be done easily. ------------------------------------------------------- Date: 2000-Sep-25 15:03 By: tim_one Comment: It's easy for the script to add this. I'd like to see it too, but only mildly -- it's a nice little check on whether all the elements actually got written out. ------------------------------------------------------- Date: 2000-Sep-25 15:19 By: lemburg Comment: Something else I noticed when I updated my CVS tree: There's a typo in the filename for the unicodectype table: it should be unicodectype_db.h, not unicodetype_db.h (note the missing "c"). ------------------------------------------------------- Date: 2000-Sep-25 15:33 By: none Comment: the tables are taken from the unidb project, and have the same names: "unicodename_db", "unicodetype_db", and "unicodedata_db". the patch summary contains a real typo, though... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101653&group_id=5470 From noreply@sourceforge.net Mon Sep 25 23:38:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 15:38:21 -0700 Subject: [Patches] [Patch #101652] unidb-based unicodectype.c replacement Message-ID: <200009252238.PAA00855@delerium.i.sourceforge.net> Patch #101652 has been updated. Project: Category: core (C code) Status: Open Summary: unidb-based unicodectype.c replacement Follow-Ups: Date: 2000-Sep-25 13:28 By: none Comment: (not a patch -- this is replacing a 450k source file with a 14k source file, and the resulting patch file is too large for sourceforge...) to generate the associated datafile, check out the latest Tools/unicode/makeunicodedata.py ------------------------------------------------------- Date: 2000-Sep-25 14:10 By: lemburg Comment: The code looks ok, but I can't really follow the technique you use for the lower/upper mappings: why can't you simply use "const Py_UNICODE" + "return ctype->lower" instead of "unsigned short" and then "return (ch + ctype->lower) & 0xffff" ?! ------------------------------------------------------- Date: 2000-Sep-25 15:38 By: none Comment: the use of "unsigned short" is from the original unidb code; I've changed this to Py_UNICODE ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101652&group_id=5470 From noreply@sourceforge.net Mon Sep 25 23:38:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 15:38:21 -0700 Subject: [Patches] [Patch #101652] unidb-based unicodectype.c replacement Message-ID: <200009252238.PAA00858@delerium.i.sourceforge.net> Patch #101652 has been updated. Project: Category: core (C code) Status: Open Summary: unidb-based unicodectype.c replacement Follow-Ups: Date: 2000-Sep-25 13:28 By: none Comment: (not a patch -- this is replacing a 450k source file with a 14k source file, and the resulting patch file is too large for sourceforge...) to generate the associated datafile, check out the latest Tools/unicode/makeunicodedata.py ------------------------------------------------------- Date: 2000-Sep-25 14:10 By: lemburg Comment: The code looks ok, but I can't really follow the technique you use for the lower/upper mappings: why can't you simply use "const Py_UNICODE" + "return ctype->lower" instead of "unsigned short" and then "return (ch + ctype->lower) & 0xffff" ?! ------------------------------------------------------- Date: 2000-Sep-25 15:38 By: none Comment: the use of "unsigned short" is from the original unidb code; I've changed this to Py_UNICODE ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101652&group_id=5470 From noreply@sourceforge.net Mon Sep 25 23:40:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 15:40:24 -0700 Subject: [Patches] [Patch #101653] unidb-based unicodetype.c replacement (part 2) Message-ID: <200009252240.PAA08660@bush.i.sourceforge.net> Patch #101653 has been updated. Project: Category: core (C code) Status: Open Summary: unidb-based unicodetype.c replacement (part 2) Follow-Ups: Date: 2000-Sep-25 14:13 By: lemburg Comment: Some compilers out there have problems with static arrays which don't specify the number of records in their constructors. Wouldn't it be possible to generate the array bounds in the generation script ? ------------------------------------------------------- Date: 2000-Sep-25 14:34 By: twouters Comment: A quick grep shows about 850 static arrays with unspecified length in the current Python source tree. I'm not against adding the length explicitly (can't hurt, after all) but it's probably not worth the trouble if it can't be done easily. ------------------------------------------------------- Date: 2000-Sep-25 15:03 By: tim_one Comment: It's easy for the script to add this. I'd like to see it too, but only mildly -- it's a nice little check on whether all the elements actually got written out. ------------------------------------------------------- Date: 2000-Sep-25 15:19 By: lemburg Comment: Something else I noticed when I updated my CVS tree: There's a typo in the filename for the unicodectype table: it should be unicodectype_db.h, not unicodetype_db.h (note the missing "c"). ------------------------------------------------------- Date: 2000-Sep-25 15:33 By: none Comment: the tables are taken from the unidb project, and have the same names: "unicodename_db", "unicodetype_db", and "unicodedata_db". the patch summary contains a real typo, though... ------------------------------------------------------- Date: 2000-Sep-25 15:40 By: lemburg Comment: Hmm, I still like unicodectype* better -- after all the ctype.h inspired the name. Since the two files belong together I'd prefer to have them use the same prefix name 'unicodectype'. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101653&group_id=5470 From noreply@sourceforge.net Mon Sep 25 23:43:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 15:43:50 -0700 Subject: [Patches] [Patch #101652] unidb-based unicodectype.c replacement Message-ID: <200009252243.PAA08828@bush.i.sourceforge.net> Patch #101652 has been updated. Project: Category: core (C code) Status: Open Summary: unidb-based unicodectype.c replacement Follow-Ups: Date: 2000-Sep-25 13:28 By: none Comment: (not a patch -- this is replacing a 450k source file with a 14k source file, and the resulting patch file is too large for sourceforge...) to generate the associated datafile, check out the latest Tools/unicode/makeunicodedata.py ------------------------------------------------------- Date: 2000-Sep-25 14:10 By: lemburg Comment: The code looks ok, but I can't really follow the technique you use for the lower/upper mappings: why can't you simply use "const Py_UNICODE" + "return ctype->lower" instead of "unsigned short" and then "return (ch + ctype->lower) & 0xffff" ?! ------------------------------------------------------- Date: 2000-Sep-25 15:38 By: none Comment: the use of "unsigned short" is from the original unidb code; I've changed this to Py_UNICODE ------------------------------------------------------- Date: 2000-Sep-25 15:43 By: lemburg Comment: There's still the "ch + ctype->upper" code in there... it would be pretty straight forward changing the offset in the database to an absolute Py_UNICODE value which I would prefer due to the possible problems with overflows and compiler warnings. Do you need the offset for something else too ? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101652&group_id=5470 From noreply@sourceforge.net Mon Sep 25 23:57:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 15:57:25 -0700 Subject: [Patches] [Patch #101653] unidb-based unicodetype.c replacement (part 2) Message-ID: <200009252257.PAA09253@bush.i.sourceforge.net> Patch #101653 has been updated. Project: Category: core (C code) Status: Open Summary: unidb-based unicodetype.c replacement (part 2) Follow-Ups: Date: 2000-Sep-25 14:13 By: lemburg Comment: Some compilers out there have problems with static arrays which don't specify the number of records in their constructors. Wouldn't it be possible to generate the array bounds in the generation script ? ------------------------------------------------------- Date: 2000-Sep-25 14:34 By: twouters Comment: A quick grep shows about 850 static arrays with unspecified length in the current Python source tree. I'm not against adding the length explicitly (can't hurt, after all) but it's probably not worth the trouble if it can't be done easily. ------------------------------------------------------- Date: 2000-Sep-25 15:03 By: tim_one Comment: It's easy for the script to add this. I'd like to see it too, but only mildly -- it's a nice little check on whether all the elements actually got written out. ------------------------------------------------------- Date: 2000-Sep-25 15:19 By: lemburg Comment: Something else I noticed when I updated my CVS tree: There's a typo in the filename for the unicodectype table: it should be unicodectype_db.h, not unicodetype_db.h (note the missing "c"). ------------------------------------------------------- Date: 2000-Sep-25 15:33 By: none Comment: the tables are taken from the unidb project, and have the same names: "unicodename_db", "unicodetype_db", and "unicodedata_db". the patch summary contains a real typo, though... ------------------------------------------------------- Date: 2000-Sep-25 15:40 By: lemburg Comment: Hmm, I still like unicodectype* better -- after all the ctype.h inspired the name. Since the two files belong together I'd prefer to have them use the same prefix name 'unicodectype'. ------------------------------------------------------- Date: 2000-Sep-25 15:57 By: tim_one Comment: C:\Code\python\dist\src\PCbuild>python Python 2.0b1 (#6, Sep 25 2000, 18:23:25) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> u"ABC".isupper() 0 >>> Doesn't look right to me. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101653&group_id=5470 From noreply@sourceforge.net Tue Sep 26 00:40:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 16:40:42 -0700 Subject: [Patches] [Patch #101652] unidb-based unicodectype.c replacement Message-ID: <200009252340.QAA03207@delerium.i.sourceforge.net> Patch #101652 has been updated. Project: Category: core (C code) Status: Closed Summary: unidb-based unicodectype.c replacement Follow-Ups: Date: 2000-Sep-25 13:28 By: none Comment: (not a patch -- this is replacing a 450k source file with a 14k source file, and the resulting patch file is too large for sourceforge...) to generate the associated datafile, check out the latest Tools/unicode/makeunicodedata.py ------------------------------------------------------- Date: 2000-Sep-25 14:10 By: lemburg Comment: The code looks ok, but I can't really follow the technique you use for the lower/upper mappings: why can't you simply use "const Py_UNICODE" + "return ctype->lower" instead of "unsigned short" and then "return (ch + ctype->lower) & 0xffff" ?! ------------------------------------------------------- Date: 2000-Sep-25 15:38 By: none Comment: the use of "unsigned short" is from the original unidb code; I've changed this to Py_UNICODE ------------------------------------------------------- Date: 2000-Sep-25 15:43 By: lemburg Comment: There's still the "ch + ctype->upper" code in there... it would be pretty straight forward changing the offset in the database to an absolute Py_UNICODE value which I would prefer due to the possible problems with overflows and compiler warnings. Do you need the offset for something else too ? ------------------------------------------------------- Date: 2000-Sep-25 16:40 By: tim_one Comment: This has been checked in and passes the tests. More fiddling has to wait until after 2.0b2 ships. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101652&group_id=5470 From noreply@sourceforge.net Tue Sep 26 00:41:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 16:41:35 -0700 Subject: [Patches] [Patch #101653] unidb-based unicodetype.c replacement (part 2) Message-ID: <200009252341.QAA03223@delerium.i.sourceforge.net> Patch #101653 has been updated. Project: Category: core (C code) Status: Closed Summary: unidb-based unicodetype.c replacement (part 2) Follow-Ups: Date: 2000-Sep-25 14:13 By: lemburg Comment: Some compilers out there have problems with static arrays which don't specify the number of records in their constructors. Wouldn't it be possible to generate the array bounds in the generation script ? ------------------------------------------------------- Date: 2000-Sep-25 14:34 By: twouters Comment: A quick grep shows about 850 static arrays with unspecified length in the current Python source tree. I'm not against adding the length explicitly (can't hurt, after all) but it's probably not worth the trouble if it can't be done easily. ------------------------------------------------------- Date: 2000-Sep-25 15:03 By: tim_one Comment: It's easy for the script to add this. I'd like to see it too, but only mildly -- it's a nice little check on whether all the elements actually got written out. ------------------------------------------------------- Date: 2000-Sep-25 15:19 By: lemburg Comment: Something else I noticed when I updated my CVS tree: There's a typo in the filename for the unicodectype table: it should be unicodectype_db.h, not unicodetype_db.h (note the missing "c"). ------------------------------------------------------- Date: 2000-Sep-25 15:33 By: none Comment: the tables are taken from the unidb project, and have the same names: "unicodename_db", "unicodetype_db", and "unicodedata_db". the patch summary contains a real typo, though... ------------------------------------------------------- Date: 2000-Sep-25 15:40 By: lemburg Comment: Hmm, I still like unicodectype* better -- after all the ctype.h inspired the name. Since the two files belong together I'd prefer to have them use the same prefix name 'unicodectype'. ------------------------------------------------------- Date: 2000-Sep-25 15:57 By: tim_one Comment: C:\Code\python\dist\src\PCbuild>python Python 2.0b1 (#6, Sep 25 2000, 18:23:25) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> u"ABC".isupper() 0 >>> Doesn't look right to me. ------------------------------------------------------- Date: 2000-Sep-25 16:41 By: tim_one Comment: This has been checked in and passes the tests. More fiddling has to wait until after 2.0b2 ships. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101653&group_id=5470 From noreply@sourceforge.net Tue Sep 26 00:46:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 16:46:12 -0700 Subject: [Patches] [Patch #101651] Gracefully detect usage of old extension module Message-ID: <200009252346.QAA03398@delerium.i.sourceforge.net> Patch #101651 has been updated. Project: Category: Windows Status: Open Summary: Gracefully detect usage of old extension module Follow-Ups: Date: 2000-Sep-25 12:49 By: loewis Comment: Also see commentary inside the patch. ------------------------------------------------------- Date: 2000-Sep-25 16:46 By: tim_one Comment: Assigned to MarkH. Mark, if you've got the bandwidth to think about this immediately, and like it, say so within the next couple of hours and I'll sneak it into 2.0b2. Else Postpone it. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101651&group_id=5470 From noreply@sourceforge.net Tue Sep 26 02:52:27 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 18:52:27 -0700 Subject: [Patches] [Patch #101394] lookdict optimizations Message-ID: <200009260152.SAA15389@bush.i.sourceforge.net> Patch #101394 has been updated. Project: Category: core (C code) Status: Postponed Summary: lookdict optimizations Follow-Ups: Date: 2000-Sep-03 21:09 By: marangoz Comment: Let's add a comment, although this has been raised on python-dev. This patch proposes a couple of ideas for optimizing & speeding dict lookups -- not all of them need to be applied though. - clear the eventual errors from Object_Compare only on need (this logic needs to be double-checked once again to see whether it really works) - defer variable initializations after the most common return cases - specialize string_compare() for lookdict_string. The test comparing the first char, before calling memcmp(), can be added too. - inline the first item probe in PyDict_GetItem. This saves a func call for the most common case (common to lookdict & lookdict_string). ------------------------------------------------------- Date: 2000-Sep-04 06:45 By: gvanrossum Comment: Quick comments: we should *always* call PyErr_Occurred() after PyObject_Compare() (and PyErr_Clear() if PyErr_Occurred() returned true). PyErr_Compare() really doesn't expect a pending exception coming in and so *not* clearing the error might break the *next* PyErr_Compare() call. (This doesn't happen typically but PyObject_Compare() can execute arbitrary code, some of which might call PyErr_Occurred() without calling PyErr_Clear() first.) ------------------------------------------------------- Date: 2000-Sep-05 06:05 By: none Comment: Correct! But then, aren't the current "else" if(cmp == 0) clauses risky after PyObject_Compare()? An exception may be set in external code while making Object_Compare() to return 0! Perhaps not in Python source, but in buggy extensions. lookdict() will then overlook this "hit". Patch updated, without "else" clauses and with the 1st char check in string_compare_equal(). ------------------------------------------------------- Date: 2000-Sep-05 06:08 By: marangoz Comment: Argh! These Web interfaces strike again - forgot to login. ------------------------------------------------------- Date: 2000-Sep-14 09:26 By: fdrake Comment: Revised patch: Instead of defining a function to do the fast string comparison, use a macro, but let it use the documented string object API (PyString_GET_SIZE(), PyString_AS_STRING()) instead of breaking the encapsulation in the code. This avoids all function calls to do the string compare, except memcmp() (which good compilers can inline anyway). Vladimir, take a look at this; if you're happy, I'm happy, and you can check it in. Thanks! ------------------------------------------------------- Date: 2000-Sep-14 13:51 By: fdrake Comment: Guido, please review (since Vladimir's away). ------------------------------------------------------- Date: 2000-Sep-15 11:18 By: gvanrossum Comment: Accepted. Assuming you've tested this, it looks fine to me. Can you time this a bit? There's one niggling issue: some people think that before you do memcmp() you should manually compare the first character. Others think that's unnecessary (since a good compiler can inline memcmp anyway). (It's also a bit scary if the size is zero.) So please ignore this but keep it in mind for timing experiments. :) ------------------------------------------------------- Date: 2000-Sep-25 14:38 By: twouters Comment: Shouldn't this patch be either postponed or checked in? ------------------------------------------------------- Date: 2000-Sep-25 18:52 By: fdrake Comment: It's postponed since I've not had time to run performance tests to measure the corner case it aims to improve. It turns out that generating the test data I need takes a long time (I need hash collisions of identifier-like strings). I just need to be able to let my generator run for a long time (it was generating more collisions than I'd expected, but I don't know how many off-hand). Another interesting metric would be to examine the .pyc files generated from the standard library and find out if there are any string hash collisions there -- if not, or if very few, it's not worth the added complexity. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101394&group_id=5470 From noreply@sourceforge.net Tue Sep 26 03:16:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 19:16:38 -0700 Subject: [Patches] [Patch #101651] Gracefully detect usage of old extension module Message-ID: <200009260216.TAA08632@delerium.i.sourceforge.net> Patch #101651 has been updated. Project: Category: Windows Status: Postponed Summary: Gracefully detect usage of old extension module Follow-Ups: Date: 2000-Sep-25 12:49 By: loewis Comment: Also see commentary inside the patch. ------------------------------------------------------- Date: 2000-Sep-25 16:46 By: tim_one Comment: Assigned to MarkH. Mark, if you've got the bandwidth to think about this immediately, and like it, say so within the next couple of hours and I'll sneak it into 2.0b2. Else Postpone it. ------------------------------------------------------- Date: 2000-Sep-25 19:16 By: mhammond Comment: My theoretical objection to this is that it may be possible for a single process to have both Python 1.5 and Python 2.0 embedded - eg, a Web server. The issue is "does the extension I just loaded reference Python15.dll", rather than simply "is python15.dll used by anyone in this process" Like I said, mainly theoretical, but there is no reason I can think of why this would not work today for people, so we can only assume it is! Marked as postponed. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101651&group_id=5470 From noreply@sourceforge.net Tue Sep 26 03:24:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 19:24:19 -0700 Subject: [Patches] [Patch #101651] Gracefully detect usage of old extension module Message-ID: <200009260224.TAA08916@delerium.i.sourceforge.net> Patch #101651 has been updated. Project: Category: Windows Status: Postponed Summary: Gracefully detect usage of old extension module Follow-Ups: Date: 2000-Sep-25 12:49 By: loewis Comment: Also see commentary inside the patch. ------------------------------------------------------- Date: 2000-Sep-25 16:46 By: tim_one Comment: Assigned to MarkH. Mark, if you've got the bandwidth to think about this immediately, and like it, say so within the next couple of hours and I'll sneak it into 2.0b2. Else Postpone it. ------------------------------------------------------- Date: 2000-Sep-25 19:16 By: mhammond Comment: My theoretical objection to this is that it may be possible for a single process to have both Python 1.5 and Python 2.0 embedded - eg, a Web server. The issue is "does the extension I just loaded reference Python15.dll", rather than simply "is python15.dll used by anyone in this process" Like I said, mainly theoretical, but there is no reason I can think of why this would not work today for people, so we can only assume it is! Marked as postponed. ------------------------------------------------------- Date: 2000-Sep-25 19:24 By: tim_one Comment: Thank you, Mark. I made enough crisis-mode work for myself by championing other last-second changes that I can't afford to argue with you now even if I wanted to . But I don't want to, so Postponing was the right thing all around. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101651&group_id=5470 From noreply@sourceforge.net Tue Sep 26 06:01:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 22:01:23 -0700 Subject: [Patches] [Patch #101659] Fix bug #115323: normalize limits.h inclusion Message-ID: <200009260501.WAA21765@bush.i.sourceforge.net> Patch #101659 has been updated. Project: Category: None Status: Open Summary: Fix bug #115323: normalize limits.h inclusion ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101659&group_id=5470 From noreply@sourceforge.net Tue Sep 26 06:13:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 22:13:02 -0700 Subject: [Patches] [Patch #101659] Fix bug #115323: normalize limits.h inclusion Message-ID: <200009260513.WAA22134@bush.i.sourceforge.net> Patch #101659 has been updated. Project: Category: core (C code) Status: Open Summary: Fix bug #115323: normalize limits.h inclusion Follow-Ups: Date: 2000-Sep-25 22:13 By: fdrake Comment: Please review. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101659&group_id=5470 From noreply@sourceforge.net Tue Sep 26 06:33:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 22:33:12 -0700 Subject: [Patches] [Patch #101659] Fix bug #115323: normalize limits.h inclusion Message-ID: <200009260533.WAA15237@delerium.i.sourceforge.net> Patch #101659 has been updated. Project: Category: core (C code) Status: Accepted Summary: Fix bug #115323: normalize limits.h inclusion Follow-Ups: Date: 2000-Sep-25 22:13 By: fdrake Comment: Please review. ------------------------------------------------------- Date: 2000-Sep-25 22:33 By: tim_one Comment: Accepted and assigned back to Fred for checkin. PythonLabs nepotism at work? Sure looks that way to me! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101659&group_id=5470 From noreply@sourceforge.net Tue Sep 26 06:58:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 22:58:41 -0700 Subject: [Patches] [Patch #101659] Fix bug #115323: normalize limits.h inclusion Message-ID: <200009260558.WAA23840@bush.i.sourceforge.net> Patch #101659 has been updated. Project: Category: core (C code) Status: Closed Summary: Fix bug #115323: normalize limits.h inclusion Follow-Ups: Date: 2000-Sep-25 22:13 By: fdrake Comment: Please review. ------------------------------------------------------- Date: 2000-Sep-25 22:33 By: tim_one Comment: Accepted and assigned back to Fred for checkin. PythonLabs nepotism at work? Sure looks that way to me! ------------------------------------------------------- Date: 2000-Sep-25 22:58 By: fdrake Comment: Checked in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101659&group_id=5470 From noreply@sourceforge.net Tue Sep 26 07:19:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 23:19:49 -0700 Subject: [Patches] [Patch #101652] unidb-based unicodectype.c replacement Message-ID: <200009260619.XAA16853@delerium.i.sourceforge.net> Patch #101652 has been updated. Project: Category: core (C code) Status: Closed Summary: unidb-based unicodectype.c replacement Follow-Ups: Date: 2000-Sep-25 13:28 By: none Comment: (not a patch -- this is replacing a 450k source file with a 14k source file, and the resulting patch file is too large for sourceforge...) to generate the associated datafile, check out the latest Tools/unicode/makeunicodedata.py ------------------------------------------------------- Date: 2000-Sep-25 14:10 By: lemburg Comment: The code looks ok, but I can't really follow the technique you use for the lower/upper mappings: why can't you simply use "const Py_UNICODE" + "return ctype->lower" instead of "unsigned short" and then "return (ch + ctype->lower) & 0xffff" ?! ------------------------------------------------------- Date: 2000-Sep-25 15:38 By: none Comment: the use of "unsigned short" is from the original unidb code; I've changed this to Py_UNICODE ------------------------------------------------------- Date: 2000-Sep-25 15:43 By: lemburg Comment: There's still the "ch + ctype->upper" code in there... it would be pretty straight forward changing the offset in the database to an absolute Py_UNICODE value which I would prefer due to the possible problems with overflows and compiler warnings. Do you need the offset for something else too ? ------------------------------------------------------- Date: 2000-Sep-25 16:40 By: tim_one Comment: This has been checked in and passes the tests. More fiddling has to wait until after 2.0b2 ships. ------------------------------------------------------- Date: 2000-Sep-25 23:19 By: none Comment: Re: "ch + ctype->upper" code. mal, deltas are an important part of the compression algorithm. if you take them away, you can no longer use the same character type descriptor for more than one character code. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101652&group_id=5470 From noreply@sourceforge.net Tue Sep 26 07:19:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Sep 2000 23:19:50 -0700 Subject: [Patches] [Patch #101652] unidb-based unicodectype.c replacement Message-ID: <200009260619.XAA16856@delerium.i.sourceforge.net> Patch #101652 has been updated. Project: Category: core (C code) Status: Closed Summary: unidb-based unicodectype.c replacement Follow-Ups: Date: 2000-Sep-25 13:28 By: none Comment: (not a patch -- this is replacing a 450k source file with a 14k source file, and the resulting patch file is too large for sourceforge...) to generate the associated datafile, check out the latest Tools/unicode/makeunicodedata.py ------------------------------------------------------- Date: 2000-Sep-25 14:10 By: lemburg Comment: The code looks ok, but I can't really follow the technique you use for the lower/upper mappings: why can't you simply use "const Py_UNICODE" + "return ctype->lower" instead of "unsigned short" and then "return (ch + ctype->lower) & 0xffff" ?! ------------------------------------------------------- Date: 2000-Sep-25 15:38 By: none Comment: the use of "unsigned short" is from the original unidb code; I've changed this to Py_UNICODE ------------------------------------------------------- Date: 2000-Sep-25 15:43 By: lemburg Comment: There's still the "ch + ctype->upper" code in there... it would be pretty straight forward changing the offset in the database to an absolute Py_UNICODE value which I would prefer due to the possible problems with overflows and compiler warnings. Do you need the offset for something else too ? ------------------------------------------------------- Date: 2000-Sep-25 16:40 By: tim_one Comment: This has been checked in and passes the tests. More fiddling has to wait until after 2.0b2 ships. ------------------------------------------------------- Date: 2000-Sep-25 23:19 By: none Comment: Re: "ch + ctype->upper" code. mal, deltas are an important part of the compression algorithm. if you take them away, you can no longer use the same character type descriptor for more than one character code. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101652&group_id=5470 From noreply@sourceforge.net Tue Sep 26 09:32:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Sep 2000 01:32:57 -0700 Subject: [Patches] [Patch #101652] unidb-based unicodectype.c replacement Message-ID: <200009260832.BAA21412@delerium.i.sourceforge.net> Patch #101652 has been updated. Project: Category: core (C code) Status: Closed Summary: unidb-based unicodectype.c replacement Follow-Ups: Date: 2000-Sep-25 13:28 By: none Comment: (not a patch -- this is replacing a 450k source file with a 14k source file, and the resulting patch file is too large for sourceforge...) to generate the associated datafile, check out the latest Tools/unicode/makeunicodedata.py ------------------------------------------------------- Date: 2000-Sep-25 14:10 By: lemburg Comment: The code looks ok, but I can't really follow the technique you use for the lower/upper mappings: why can't you simply use "const Py_UNICODE" + "return ctype->lower" instead of "unsigned short" and then "return (ch + ctype->lower) & 0xffff" ?! ------------------------------------------------------- Date: 2000-Sep-25 15:38 By: none Comment: the use of "unsigned short" is from the original unidb code; I've changed this to Py_UNICODE ------------------------------------------------------- Date: 2000-Sep-25 15:43 By: lemburg Comment: There's still the "ch + ctype->upper" code in there... it would be pretty straight forward changing the offset in the database to an absolute Py_UNICODE value which I would prefer due to the possible problems with overflows and compiler warnings. Do you need the offset for something else too ? ------------------------------------------------------- Date: 2000-Sep-25 16:40 By: tim_one Comment: This has been checked in and passes the tests. More fiddling has to wait until after 2.0b2 ships. ------------------------------------------------------- Date: 2000-Sep-25 23:19 By: none Comment: Re: "ch + ctype->upper" code. mal, deltas are an important part of the compression algorithm. if you take them away, you can no longer use the same character type descriptor for more than one character code. ------------------------------------------------------- Date: 2000-Sep-26 01:32 By: lemburg Comment: I see. Well then we'll have to live with it I guess. I think we'll also need a regression test for the Unicode database. Since putting another 500k of output into the distro is not ideal, I' d suggest to use SHA on the output and then only write the hash value to the test output file. I'll see if I can come up with such a beast today. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101652&group_id=5470 From noreply@sourceforge.net Tue Sep 26 11:00:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Sep 2000 03:00:21 -0700 Subject: [Patches] [Patch #101652] unidb-based unicodectype.c replacement Message-ID: <200009261000.DAA32575@bush.i.sourceforge.net> Patch #101652 has been updated. Project: Category: core (C code) Status: Closed Summary: unidb-based unicodectype.c replacement Follow-Ups: Date: 2000-Sep-25 13:28 By: none Comment: (not a patch -- this is replacing a 450k source file with a 14k source file, and the resulting patch file is too large for sourceforge...) to generate the associated datafile, check out the latest Tools/unicode/makeunicodedata.py ------------------------------------------------------- Date: 2000-Sep-25 14:10 By: lemburg Comment: The code looks ok, but I can't really follow the technique you use for the lower/upper mappings: why can't you simply use "const Py_UNICODE" + "return ctype->lower" instead of "unsigned short" and then "return (ch + ctype->lower) & 0xffff" ?! ------------------------------------------------------- Date: 2000-Sep-25 15:38 By: none Comment: the use of "unsigned short" is from the original unidb code; I've changed this to Py_UNICODE ------------------------------------------------------- Date: 2000-Sep-25 15:43 By: lemburg Comment: There's still the "ch + ctype->upper" code in there... it would be pretty straight forward changing the offset in the database to an absolute Py_UNICODE value which I would prefer due to the possible problems with overflows and compiler warnings. Do you need the offset for something else too ? ------------------------------------------------------- Date: 2000-Sep-25 16:40 By: tim_one Comment: This has been checked in and passes the tests. More fiddling has to wait until after 2.0b2 ships. ------------------------------------------------------- Date: 2000-Sep-25 23:19 By: none Comment: Re: "ch + ctype->upper" code. mal, deltas are an important part of the compression algorithm. if you take them away, you can no longer use the same character type descriptor for more than one character code. ------------------------------------------------------- Date: 2000-Sep-26 01:32 By: lemburg Comment: I see. Well then we'll have to live with it I guess. I think we'll also need a regression test for the Unicode database. Since putting another 500k of output into the distro is not ideal, I' d suggest to use SHA on the output and then only write the hash value to the test output file. I'll see if I can come up with such a beast today. ------------------------------------------------------- Date: 2000-Sep-26 03:00 By: effbot Comment: fwiw, I used such a script to verify that my changes didn't change a single database entry. The main reason I didn't add it to the test suite is that takes quite a while to loop over 64k characters... Anyway, I'll post the script later today. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101652&group_id=5470 From noreply@sourceforge.net Tue Sep 26 11:01:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Sep 2000 03:01:01 -0700 Subject: [Patches] [Patch #101653] unidb-based unicodetype.c replacement (part 2) Message-ID: <200009261001.DAA32584@bush.i.sourceforge.net> Patch #101653 has been updated. Project: Category: core (C code) Status: Closed Summary: unidb-based unicodetype.c replacement (part 2) Follow-Ups: Date: 2000-Sep-25 14:13 By: lemburg Comment: Some compilers out there have problems with static arrays which don't specify the number of records in their constructors. Wouldn't it be possible to generate the array bounds in the generation script ? ------------------------------------------------------- Date: 2000-Sep-25 14:34 By: twouters Comment: A quick grep shows about 850 static arrays with unspecified length in the current Python source tree. I'm not against adding the length explicitly (can't hurt, after all) but it's probably not worth the trouble if it can't be done easily. ------------------------------------------------------- Date: 2000-Sep-25 15:03 By: tim_one Comment: It's easy for the script to add this. I'd like to see it too, but only mildly -- it's a nice little check on whether all the elements actually got written out. ------------------------------------------------------- Date: 2000-Sep-25 15:19 By: lemburg Comment: Something else I noticed when I updated my CVS tree: There's a typo in the filename for the unicodectype table: it should be unicodectype_db.h, not unicodetype_db.h (note the missing "c"). ------------------------------------------------------- Date: 2000-Sep-25 15:33 By: none Comment: the tables are taken from the unidb project, and have the same names: "unicodename_db", "unicodetype_db", and "unicodedata_db". the patch summary contains a real typo, though... ------------------------------------------------------- Date: 2000-Sep-25 15:40 By: lemburg Comment: Hmm, I still like unicodectype* better -- after all the ctype.h inspired the name. Since the two files belong together I'd prefer to have them use the same prefix name 'unicodectype'. ------------------------------------------------------- Date: 2000-Sep-25 15:57 By: tim_one Comment: C:\Code\python\dist\src\PCbuild>python Python 2.0b1 (#6, Sep 25 2000, 18:23:25) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> u"ABC".isupper() 0 >>> Doesn't look right to me. ------------------------------------------------------- Date: 2000-Sep-25 16:41 By: tim_one Comment: This has been checked in and passes the tests. More fiddling has to wait until after 2.0b2 ships. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101653&group_id=5470 From noreply@sourceforge.net Tue Sep 26 11:24:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Sep 2000 03:24:53 -0700 Subject: [Patches] [Patch #101663] Regression test for Unicode database Message-ID: <200009261024.DAA25362@delerium.i.sourceforge.net> Patch #101663 has been updated. Project: Category: library Status: Open Summary: Regression test for Unicode database ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101663&group_id=5470 From noreply@sourceforge.net Tue Sep 26 11:27:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Sep 2000 03:27:46 -0700 Subject: [Patches] [Patch #101663] Regression test for Unicode database Message-ID: <200009261027.DAA25420@delerium.i.sourceforge.net> Patch #101663 has been updated. Project: Category: library Status: Open Summary: Regression test for Unicode database Follow-Ups: Date: 2000-Sep-26 03:27 By: lemburg Comment: This is a regression test for the available Unicode database methods and functions. There's one problem with it: it takes a few seconds to run because it has to check 64k characters... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101663&group_id=5470 From noreply@sourceforge.net Tue Sep 26 12:06:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Sep 2000 04:06:44 -0700 Subject: [Patches] [Patch #101664] Add new unistr() builtin + PyObject_Unicode() C API Message-ID: <200009261106.EAA02617@bush.i.sourceforge.net> Patch #101664 has been updated. Project: Category: core (C code) Status: Open Summary: Add new unistr() builtin + PyObject_Unicode() C API ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101664&group_id=5470 From noreply@sourceforge.net Tue Sep 26 12:08:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Sep 2000 04:08:56 -0700 Subject: [Patches] [Patch #101663] Regression test for Unicode database Message-ID: <200009261108.EAA02645@bush.i.sourceforge.net> Patch #101663 has been updated. Project: Category: library Status: Open Summary: Regression test for Unicode database Follow-Ups: Date: 2000-Sep-26 03:27 By: lemburg Comment: This is a regression test for the available Unicode database methods and functions. There's one problem with it: it takes a few seconds to run because it has to check 64k characters... ------------------------------------------------------- Date: 2000-Sep-26 04:08 By: none Comment: umm. you did mean "return h.hexdigest()" rather than "return repr(h)", didn't you? I also think the code is quite a bit more hypergeneralized (read slow) than it really has to be... (e.g. if a method is missing or chokes on the data, why pretend it returned an empty string?) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101663&group_id=5470 From noreply@sourceforge.net Tue Sep 26 12:08:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Sep 2000 04:08:56 -0700 Subject: [Patches] [Patch #101663] Regression test for Unicode database Message-ID: <200009261108.EAA02642@bush.i.sourceforge.net> Patch #101663 has been updated. Project: Category: library Status: Open Summary: Regression test for Unicode database Follow-Ups: Date: 2000-Sep-26 03:27 By: lemburg Comment: This is a regression test for the available Unicode database methods and functions. There's one problem with it: it takes a few seconds to run because it has to check 64k characters... ------------------------------------------------------- Date: 2000-Sep-26 04:08 By: none Comment: umm. you did mean "return h.hexdigest()" rather than "return repr(h)", didn't you? I also think the code is quite a bit more hypergeneralized (read slow) than it really has to be... (e.g. if a method is missing or chokes on the data, why pretend it returned an empty string?) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101663&group_id=5470 From noreply@sourceforge.net Tue Sep 26 12:13:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Sep 2000 04:13:48 -0700 Subject: [Patches] [Patch #101663] Regression test for Unicode database Message-ID: <200009261113.EAA02831@bush.i.sourceforge.net> Patch #101663 has been updated. Project: Category: library Status: Open Summary: Regression test for Unicode database Follow-Ups: Date: 2000-Sep-26 03:27 By: lemburg Comment: This is a regression test for the available Unicode database methods and functions. There's one problem with it: it takes a few seconds to run because it has to check 64k characters... ------------------------------------------------------- Date: 2000-Sep-26 04:08 By: none Comment: umm. you did mean "return h.hexdigest()" rather than "return repr(h)", didn't you? I also think the code is quite a bit more hypergeneralized (read slow) than it really has to be... (e.g. if a method is missing or chokes on the data, why pretend it returned an empty string?) ------------------------------------------------------- Date: 2000-Sep-26 04:13 By: lemburg Comment: RE: .hexdigest: good idea ! RE: generalization: the exception handling is needed because some methods raise errors for e.g. non-numbers. I don't think that inlining the tests will change much about the execution speed... it will still be slow. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101663&group_id=5470 From noreply@sourceforge.net Tue Sep 26 12:14:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Sep 2000 04:14:01 -0700 Subject: [Patches] [Patch #101664] Add new unistr() builtin + PyObject_Unicode() C API Message-ID: <200009261114.EAA02835@bush.i.sourceforge.net> Patch #101664 has been updated. Project: Category: core (C code) Status: Postponed Summary: Add new unistr() builtin + PyObject_Unicode() C API Follow-Ups: Date: 2000-Sep-26 04:14 By: lemburg Comment: This patch adds a utility function unistr() which works just like the standard builtin str() -- only that the return value will always be a Unicode object. The patch also adds a new object level C API PyObject_Unicode() which complements PyObject_Str(). Since this is a new feature, I have postponed the patch to be reopened in the 2.1 cycle. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101664&group_id=5470 From noreply@sourceforge.net Tue Sep 26 12:43:27 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Sep 2000 04:43:27 -0700 Subject: [Patches] [Patch #101663] Regression test for Unicode database Message-ID: <200009261143.EAA03878@bush.i.sourceforge.net> Patch #101663 has been updated. Project: Category: library Status: Open Summary: Regression test for Unicode database Follow-Ups: Date: 2000-Sep-26 03:27 By: lemburg Comment: This is a regression test for the available Unicode database methods and functions. There's one problem with it: it takes a few seconds to run because it has to check 64k characters... ------------------------------------------------------- Date: 2000-Sep-26 04:08 By: none Comment: umm. you did mean "return h.hexdigest()" rather than "return repr(h)", didn't you? I also think the code is quite a bit more hypergeneralized (read slow) than it really has to be... (e.g. if a method is missing or chokes on the data, why pretend it returned an empty string?) ------------------------------------------------------- Date: 2000-Sep-26 04:13 By: lemburg Comment: RE: .hexdigest: good idea ! RE: generalization: the exception handling is needed because some methods raise errors for e.g. non-numbers. I don't think that inlining the tests will change much about the execution speed... it will still be slow. ------------------------------------------------------- Date: 2000-Sep-26 04:43 By: none Comment: RE: exceptions: but if you spell things out, you can use the "default" argument to get rid of the exception. Here's the main body from my version of this script (this assumes that 'repr' does the right thing, of course). To cope with a missing unicodedata module, just split the tuple in two parts, updating two different digests. 
for i in range(65536):
    char = unichr(i)
    data = (
        # ctype predicates
        char.isalnum(),
        char.isalpha(),
        char.isdecimal(),
        char.isdigit(),
        char.islower(),
        char.isnumeric(),
        char.isspace(),
        char.istitle(),
        char.isupper(),
        # ctype mappings
        char.lower(),
        char.upper(),
        char.title(),
        # properties
        unicodedata.digit(char, None),
        unicodedata.numeric(char, None),
        unicodedata.decimal(char, None),
        unicodedata.category(char),
        unicodedata.bidirectional(char),
        unicodedata.decomposition(char),
        unicodedata.mirrored(char),
        unicodedata.combining(char)
        )
    h.update(repr(data))
BTW, note that "islower/upper/title" tests more than just the IsLower/etc predicates; maybe they should be written as "char*3" or "char+'constant string'" to catch bogus combinations of attributes. My first checkin had a broken IsTitle table, but the test didn't spot that because it just checked a single character... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101663&group_id=5470 From noreply@sourceforge.net Tue Sep 26 12:43:27 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Sep 2000 04:43:27 -0700 Subject: [Patches] [Patch #101663] Regression test for Unicode database Message-ID: <200009261143.EAA03875@bush.i.sourceforge.net> Patch #101663 has been updated. Project: Category: library Status: Open Summary: Regression test for Unicode database Follow-Ups: Date: 2000-Sep-26 03:27 By: lemburg Comment: This is a regression test for the available Unicode database methods and functions. There's one problem with it: it takes a few seconds to run because it has to check 64k characters... ------------------------------------------------------- Date: 2000-Sep-26 04:08 By: none Comment: umm. you did mean "return h.hexdigest()" rather than "return repr(h)", didn't you? I also think the code is quite a bit more hypergeneralized (read slow) than it really has to be... (e.g. if a method is missing or chokes on the data, why pretend it returned an empty string?) ------------------------------------------------------- Date: 2000-Sep-26 04:13 By: lemburg Comment: RE: .hexdigest: good idea ! RE: generalization: the exception handling is needed because some methods raise errors for e.g. non-numbers. I don't think that inlining the tests will change much about the execution speed... it will still be slow. ------------------------------------------------------- Date: 2000-Sep-26 04:43 By: none Comment: RE: exceptions: but if you spell things out, you can use the "default" argument to get rid of the exception. Here's the main body from my version of this script (this assumes that 'repr' does the right thing, of course). To cope with a missing unicodedata module, just split the tuple in two parts, updating two different digests. 
for i in range(65536):
    char = unichr(i)
    data = (
        # ctype predicates
        char.isalnum(),
        char.isalpha(),
        char.isdecimal(),
        char.isdigit(),
        char.islower(),
        char.isnumeric(),
        char.isspace(),
        char.istitle(),
        char.isupper(),
        # ctype mappings
        char.lower(),
        char.upper(),
        char.title(),
        # properties
        unicodedata.digit(char, None),
        unicodedata.numeric(char, None),
        unicodedata.decimal(char, None),
        unicodedata.category(char),
        unicodedata.bidirectional(char),
        unicodedata.decomposition(char),
        unicodedata.mirrored(char),
        unicodedata.combining(char)
        )
    h.update(repr(data))
BTW, note that "islower/upper/title" tests more than just the IsLower/etc predicates; maybe they should be written as "char*3" or "char+'constant string'" to catch bogus combinations of attributes. My first checkin had a broken IsTitle table, but the test didn't spot that because it just checked a single character... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101663&group_id=5470 From noreply@sourceforge.net Tue Sep 26 12:49:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Sep 2000 04:49:04 -0700 Subject: [Patches] [Patch #101663] Regression test for Unicode database Message-ID: <200009261149.EAA04075@bush.i.sourceforge.net> Patch #101663 has been updated. Project: Category: library Status: Open Summary: Regression test for Unicode database Follow-Ups: Date: 2000-Sep-26 03:27 By: lemburg Comment: This is a regression test for the available Unicode database methods and functions. There's one problem with it: it takes a few seconds to run because it has to check 64k characters... ------------------------------------------------------- Date: 2000-Sep-26 04:08 By: none Comment: umm. you did mean "return h.hexdigest()" rather than "return repr(h)", didn't you? I also think the code is quite a bit more hypergeneralized (read slow) than it really has to be... (e.g. if a method is missing or chokes on the data, why pretend it returned an empty string?) ------------------------------------------------------- Date: 2000-Sep-26 04:13 By: lemburg Comment: RE: .hexdigest: good idea ! RE: generalization: the exception handling is needed because some methods raise errors for e.g. non-numbers. I don't think that inlining the tests will change much about the execution speed... it will still be slow. ------------------------------------------------------- Date: 2000-Sep-26 04:43 By: none Comment: RE: exceptions: but if you spell things out, you can use the "default" argument to get rid of the exception. Here's the main body from my version of this script (this assumes that 'repr' does the right thing, of course). To cope with a missing unicodedata module, just split the tuple in two parts, updating two different digests. 
for i in range(65536):
    char = unichr(i)
    data = (
        # ctype predicates
        char.isalnum(),
        char.isalpha(),
        char.isdecimal(),
        char.isdigit(),
        char.islower(),
        char.isnumeric(),
        char.isspace(),
        char.istitle(),
        char.isupper(),
        # ctype mappings
        char.lower(),
        char.upper(),
        char.title(),
        # properties
        unicodedata.digit(char, None),
        unicodedata.numeric(char, None),
        unicodedata.decimal(char, None),
        unicodedata.category(char),
        unicodedata.bidirectional(char),
        unicodedata.decomposition(char),
        unicodedata.mirrored(char),
        unicodedata.combining(char)
        )
    h.update(repr(data))
BTW, note that "islower/upper/title" tests more than just the IsLower/etc predicates; maybe they should be written as "char*3" or "char+'constant string'" to catch bogus combinations of attributes. My first checkin had a broken IsTitle table, but the test didn't spot that because it just checked a single character... ------------------------------------------------------- Date: 2000-Sep-26 04:49 By: gvanrossum Comment: Marc-Andre, the test output is not portable -- it contains three instances: . ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101663&group_id=5470 From noreply@sourceforge.net Tue Sep 26 13:33:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Sep 2000 05:33:58 -0700 Subject: [Patches] [Patch #101663] Regression test for Unicode database Message-ID: <200009261233.FAA29974@delerium.i.sourceforge.net> Patch #101663 has been updated. Project: Category: library Status: Open Summary: Regression test for Unicode database Follow-Ups: Date: 2000-Sep-26 03:27 By: lemburg Comment: This is a regression test for the available Unicode database methods and functions. There's one problem with it: it takes a few seconds to run because it has to check 64k characters... ------------------------------------------------------- Date: 2000-Sep-26 04:08 By: none Comment: umm. you did mean "return h.hexdigest()" rather than "return repr(h)", didn't you? I also think the code is quite a bit more hypergeneralized (read slow) than it really has to be... (e.g. if a method is missing or chokes on the data, why pretend it returned an empty string?) ------------------------------------------------------- Date: 2000-Sep-26 04:13 By: lemburg Comment: RE: .hexdigest: good idea ! RE: generalization: the exception handling is needed because some methods raise errors for e.g. non-numbers. I don't think that inlining the tests will change much about the execution speed... it will still be slow. ------------------------------------------------------- Date: 2000-Sep-26 04:43 By: none Comment: RE: exceptions: but if you spell things out, you can use the "default" argument to get rid of the exception. Here's the main body from my version of this script (this assumes that 'repr' does the right thing, of course). To cope with a missing unicodedata module, just split the tuple in two parts, updating two different digests. 
for i in range(65536):
    char = unichr(i)
    data = (
        # ctype predicates
        char.isalnum(),
        char.isalpha(),
        char.isdecimal(),
        char.isdigit(),
        char.islower(),
        char.isnumeric(),
        char.isspace(),
        char.istitle(),
        char.isupper(),
        # ctype mappings
        char.lower(),
        char.upper(),
        char.title(),
        # properties
        unicodedata.digit(char, None),
        unicodedata.numeric(char, None),
        unicodedata.decimal(char, None),
        unicodedata.category(char),
        unicodedata.bidirectional(char),
        unicodedata.decomposition(char),
        unicodedata.mirrored(char),
        unicodedata.combining(char)
        )
    h.update(repr(data))
BTW, note that "islower/upper/title" tests more than just the IsLower/etc predicates; maybe they should be written as "char*3" or "char+'constant string'" to catch bogus combinations of attributes. My first checkin had a broken IsTitle table, but the test didn't spot that because it just checked a single character... ------------------------------------------------------- Date: 2000-Sep-26 04:49 By: gvanrossum Comment: Marc-Andre, the test output is not portable -- it contains three instances: . ------------------------------------------------------- Date: 2000-Sep-26 05:33 By: lemburg Comment: Here's an updated patch that fixes all of the above... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101663&group_id=5470 From noreply@sourceforge.net Tue Sep 26 16:07:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Sep 2000 08:07:38 -0700 Subject: [Patches] [Patch #101663] Regression test for Unicode database Message-ID: <200009261507.IAA11869@bush.i.sourceforge.net> Patch #101663 has been updated. Project: Category: library Status: Open Summary: Regression test for Unicode database Follow-Ups: Date: 2000-Sep-26 03:27 By: lemburg Comment: This is a regression test for the available Unicode database methods and functions. There's one problem with it: it takes a few seconds to run because it has to check 64k characters... ------------------------------------------------------- Date: 2000-Sep-26 04:08 By: none Comment: umm. you did mean "return h.hexdigest()" rather than "return repr(h)", didn't you? I also think the code is quite a bit more hypergeneralized (read slow) than it really has to be... (e.g. if a method is missing or chokes on the data, why pretend it returned an empty string?) ------------------------------------------------------- Date: 2000-Sep-26 04:13 By: lemburg Comment: RE: .hexdigest: good idea ! RE: generalization: the exception handling is needed because some methods raise errors for e.g. non-numbers. I don't think that inlining the tests will change much about the execution speed... it will still be slow. ------------------------------------------------------- Date: 2000-Sep-26 04:43 By: none Comment: RE: exceptions: but if you spell things out, you can use the "default" argument to get rid of the exception. Here's the main body from my version of this script (this assumes that 'repr' does the right thing, of course). To cope with a missing unicodedata module, just split the tuple in two parts, updating two different digests. 
for i in range(65536):
    char = unichr(i)
    data = (
        # ctype predicates
        char.isalnum(),
        char.isalpha(),
        char.isdecimal(),
        char.isdigit(),
        char.islower(),
        char.isnumeric(),
        char.isspace(),
        char.istitle(),
        char.isupper(),
        # ctype mappings
        char.lower(),
        char.upper(),
        char.title(),
        # properties
        unicodedata.digit(char, None),
        unicodedata.numeric(char, None),
        unicodedata.decimal(char, None),
        unicodedata.category(char),
        unicodedata.bidirectional(char),
        unicodedata.decomposition(char),
        unicodedata.mirrored(char),
        unicodedata.combining(char)
        )
    h.update(repr(data))
BTW, note that "islower/upper/title" tests more than just the IsLower/etc predicates; maybe they should be written as "char*3" or "char+'constant string'" to catch bogus combinations of attributes. My first checkin had a broken IsTitle table, but the test didn't spot that because it just checked a single character... ------------------------------------------------------- Date: 2000-Sep-26 04:49 By: gvanrossum Comment: Marc-Andre, the test output is not portable -- it contains three instances: . ------------------------------------------------------- Date: 2000-Sep-26 05:33 By: lemburg Comment: Here's an updated patch that fixes all of the above... ------------------------------------------------------- Date: 2000-Sep-26 08:07 By: none Comment: +1 from here! /F ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101663&group_id=5470 From noreply@sourceforge.net Tue Sep 26 16:07:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Sep 2000 08:07:38 -0700 Subject: [Patches] [Patch #101663] Regression test for Unicode database Message-ID: <200009261507.IAA11872@bush.i.sourceforge.net> Patch #101663 has been updated. Project: Category: library Status: Open Summary: Regression test for Unicode database Follow-Ups: Date: 2000-Sep-26 03:27 By: lemburg Comment: This is a regression test for the available Unicode database methods and functions. There's one problem with it: it takes a few seconds to run because it has to check 64k characters... ------------------------------------------------------- Date: 2000-Sep-26 04:08 By: none Comment: umm. you did mean "return h.hexdigest()" rather than "return repr(h)", didn't you? I also think the code is quite a bit more hypergeneralized (read slow) than it really has to be... (e.g. if a method is missing or chokes on the data, why pretend it returned an empty string?) ------------------------------------------------------- Date: 2000-Sep-26 04:13 By: lemburg Comment: RE: .hexdigest: good idea ! RE: generalization: the exception handling is needed because some methods raise errors for e.g. non-numbers. I don't think that inlining the tests will change much about the execution speed... it will still be slow. ------------------------------------------------------- Date: 2000-Sep-26 04:43 By: none Comment: RE: exceptions: but if you spell things out, you can use the "default" argument to get rid of the exception. Here's the main body from my version of this script (this assumes that 'repr' does the right thing, of course). To cope with a missing unicodedata module, just split the tuple in two parts, updating two different digests. 
for i in range(65536):
    char = unichr(i)
    data = (
        # ctype predicates
        char.isalnum(),
        char.isalpha(),
        char.isdecimal(),
        char.isdigit(),
        char.islower(),
        char.isnumeric(),
        char.isspace(),
        char.istitle(),
        char.isupper(),
        # ctype mappings
        char.lower(),
        char.upper(),
        char.title(),
        # properties
        unicodedata.digit(char, None),
        unicodedata.numeric(char, None),
        unicodedata.decimal(char, None),
        unicodedata.category(char),
        unicodedata.bidirectional(char),
        unicodedata.decomposition(char),
        unicodedata.mirrored(char),
        unicodedata.combining(char)
        )
    h.update(repr(data))
BTW, note that "islower/upper/title" tests more than just the IsLower/etc predicates; maybe they should be written as "char*3" or "char+'constant string'" to catch bogus combinations of attributes. My first checkin had a broken IsTitle table, but the test didn't spot that because it just checked a single character... ------------------------------------------------------- Date: 2000-Sep-26 04:49 By: gvanrossum Comment: Marc-Andre, the test output is not portable -- it contains three instances: . ------------------------------------------------------- Date: 2000-Sep-26 05:33 By: lemburg Comment: Here's an updated patch that fixes all of the above... ------------------------------------------------------- Date: 2000-Sep-26 08:07 By: none Comment: +1 from here! /F ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101663&group_id=5470 From noreply@sourceforge.net Tue Sep 26 16:16:20 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Sep 2000 08:16:20 -0700 Subject: [Patches] [Patch #101663] Regression test for Unicode database Message-ID: <200009261516.IAA03860@delerium.i.sourceforge.net> Patch #101663 has been updated. Project: Category: library Status: Accepted Summary: Regression test for Unicode database Follow-Ups: Date: 2000-Sep-26 03:27 By: lemburg Comment: This is a regression test for the available Unicode database methods and functions. There's one problem with it: it takes a few seconds to run because it has to check 64k characters... ------------------------------------------------------- Date: 2000-Sep-26 04:08 By: none Comment: umm. you did mean "return h.hexdigest()" rather than "return repr(h)", didn't you? I also think the code is quite a bit more hypergeneralized (read slow) than it really has to be... (e.g. if a method is missing or chokes on the data, why pretend it returned an empty string?) ------------------------------------------------------- Date: 2000-Sep-26 04:13 By: lemburg Comment: RE: .hexdigest: good idea ! RE: generalization: the exception handling is needed because some methods raise errors for e.g. non-numbers. I don't think that inlining the tests will change much about the execution speed... it will still be slow. ------------------------------------------------------- Date: 2000-Sep-26 04:43 By: none Comment: RE: exceptions: but if you spell things out, you can use the "default" argument to get rid of the exception. Here's the main body from my version of this script (this assumes that 'repr' does the right thing, of course). To cope with a missing unicodedata module, just split the tuple in two parts, updating two different digests. 
for i in range(65536):
    char = unichr(i)
    data = (
        # ctype predicates
        char.isalnum(),
        char.isalpha(),
        char.isdecimal(),
        char.isdigit(),
        char.islower(),
        char.isnumeric(),
        char.isspace(),
        char.istitle(),
        char.isupper(),
        # ctype mappings
        char.lower(),
        char.upper(),
        char.title(),
        # properties
        unicodedata.digit(char, None),
        unicodedata.numeric(char, None),
        unicodedata.decimal(char, None),
        unicodedata.category(char),
        unicodedata.bidirectional(char),
        unicodedata.decomposition(char),
        unicodedata.mirrored(char),
        unicodedata.combining(char)
        )
    h.update(repr(data))
BTW, note that "islower/upper/title" tests more than just the IsLower/etc predicates; maybe they should be written as "char*3" or "char+'constant string'" to catch bogus combinations of attributes. My first checkin had a broken IsTitle table, but the test didn't spot that because it just checked a single character... ------------------------------------------------------- Date: 2000-Sep-26 04:49 By: gvanrossum Comment: Marc-Andre, the test output is not portable -- it contains three instances: . ------------------------------------------------------- Date: 2000-Sep-26 05:33 By: lemburg Comment: Here's an updated patch that fixes all of the above... ------------------------------------------------------- Date: 2000-Sep-26 08:07 By: none Comment: +1 from here! /F ------------------------------------------------------- Date: 2000-Sep-26 08:16 By: jhylton Comment: (Don't tell anyone, but if you do this quickly we'll put it in 2.0b2.) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101663&group_id=5470 From noreply@sourceforge.net Tue Sep 26 17:20:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Sep 2000 09:20:12 -0700 Subject: [Patches] [Patch #101663] Regression test for Unicode database Message-ID: <200009261620.JAA06365@delerium.i.sourceforge.net> Patch #101663 has been updated. Project: Category: library Status: Closed Summary: Regression test for Unicode database Follow-Ups: Date: 2000-Sep-26 03:27 By: lemburg Comment: This is a regression test for the available Unicode database methods and functions. There's one problem with it: it takes a few seconds to run because it has to check 64k characters... ------------------------------------------------------- Date: 2000-Sep-26 04:08 By: none Comment: umm. you did mean "return h.hexdigest()" rather than "return repr(h)", didn't you? I also think the code is quite a bit more hypergeneralized (read slow) than it really has to be... (e.g. if a method is missing or chokes on the data, why pretend it returned an empty string?) ------------------------------------------------------- Date: 2000-Sep-26 04:13 By: lemburg Comment: RE: .hexdigest: good idea ! RE: generalization: the exception handling is needed because some methods raise errors for e.g. non-numbers. I don't think that inlining the tests will change much about the execution speed... it will still be slow. ------------------------------------------------------- Date: 2000-Sep-26 04:43 By: none Comment: RE: exceptions: but if you spell things out, you can use the "default" argument to get rid of the exception. Here's the main body from my version of this script (this assumes that 'repr' does the right thing, of course). To cope with a missing unicodedata module, just split the tuple in two parts, updating two different digests. 
for i in range(65536):
    char = unichr(i)
    data = (
        # ctype predicates
        char.isalnum(),
        char.isalpha(),
        char.isdecimal(),
        char.isdigit(),
        char.islower(),
        char.isnumeric(),
        char.isspace(),
        char.istitle(),
        char.isupper(),
        # ctype mappings
        char.lower(),
        char.upper(),
        char.title(),
        # properties
        unicodedata.digit(char, None),
        unicodedata.numeric(char, None),
        unicodedata.decimal(char, None),
        unicodedata.category(char),
        unicodedata.bidirectional(char),
        unicodedata.decomposition(char),
        unicodedata.mirrored(char),
        unicodedata.combining(char)
        )
    h.update(repr(data))
BTW, note that "islower/upper/title" tests more than just the IsLower/etc predicates; maybe they should be written as "char*3" or "char+'constant string'" to catch bogus combinations of attributes. My first checkin had a broken IsTitle table, but the test didn't spot that because it just checked a single character... ------------------------------------------------------- Date: 2000-Sep-26 04:49 By: gvanrossum Comment: Marc-Andre, the test output is not portable -- it contains three instances: . ------------------------------------------------------- Date: 2000-Sep-26 05:33 By: lemburg Comment: Here's an updated patch that fixes all of the above... ------------------------------------------------------- Date: 2000-Sep-26 08:07 By: none Comment: +1 from here! /F ------------------------------------------------------- Date: 2000-Sep-26 08:16 By: jhylton Comment: (Don't tell anyone, but if you do this quickly we'll put it in 2.0b2.) ------------------------------------------------------- Date: 2000-Sep-26 09:20 By: lemburg Comment: Checked in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101663&group_id=5470 From noreply@sourceforge.net Wed Sep 27 06:33:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Sep 2000 22:33:37 -0700 Subject: [Patches] [Patch #101676] Detect conflicting Python DLL on module import under Windows Message-ID: <200009270533.WAA02565@delerium.i.sourceforge.net> Patch #101676 has been updated. Project: Category: core (C code) Status: Open Summary: Detect conflicting Python DLL on module import under Windows ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101676&group_id=5470 From noreply@sourceforge.net Wed Sep 27 06:49:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Sep 2000 22:49:02 -0700 Subject: [Patches] [Patch #101676] Detect conflicting Python DLL on module import under Windows Message-ID: <200009270549.WAA03053@delerium.i.sourceforge.net> Patch #101676 has been updated. Project: Category: core (C code) Status: Open Summary: Detect conflicting Python DLL on module import under Windows Follow-Ups: Date: 2000-Sep-26 22:49 By: db3l Comment: This patch is an attempt to provide similar functionality to an earlier proposed patch (101651) but addressing Mark's concern about a process having two DLLs loaded explicitly. This patch parses the actual module import table after the module has been loaded into memory to determine which Python DLL (identified by a "python" prefix followed by just numbers) is loaded specifically by the module as opposed to just being in the process space, and compares that to the current Python version, complaining (and identifying the referenced DLL in the error) if there is a mismatch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101676&group_id=5470 From noreply@sourceforge.net Wed Sep 27 06:50:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Sep 2000 22:50:33 -0700 Subject: [Patches] [Patch #101676] Detect conflicting Python DLL on module import under Windows Message-ID: <200009270550.WAA03071@delerium.i.sourceforge.net> Patch #101676 has been updated. Project: Category: core (C code) Status: Open Summary: Detect conflicting Python DLL on module import under Windows Follow-Ups: Date: 2000-Sep-26 22:49 By: db3l Comment: This patch is an attempt to provide similar functionality to an earlier proposed patch (101651) but addressing Mark's concern about a process having two DLLs loaded explicitly. This patch parses the actual module import table after the module has been loaded into memory to determine which Python DLL (identified by a "python" prefix followed by just numbers) is loaded specifically by the module as opposed to just being in the process space, and compares that to the current Python version, complaining (and identifying the referenced DLL in the error) if there is a mismatch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101676&group_id=5470 From noreply@sourceforge.net Wed Sep 27 06:49:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Sep 2000 22:49:02 -0700 Subject: [Patches] [Patch #101676] Detect conflicting Python DLL on module import under Windows Message-ID: <200009270549.WAA03056@delerium.i.sourceforge.net> Patch #101676 has been updated. Project: Category: core (C code) Status: Open Summary: Detect conflicting Python DLL on module import under Windows Follow-Ups: Date: 2000-Sep-26 22:49 By: db3l Comment: This patch is an attempt to provide similar functionality to an earlier proposed patch (101651) but addressing Mark's concern about a process having two DLLs loaded explicitly. This patch parses the actual module import table after the module has been loaded into memory to determine which Python DLL (identified by a "python" prefix followed by just numbers) is loaded specifically by the module as opposed to just being in the process space, and compares that to the current Python version, complaining (and identifying the referenced DLL in the error) if there is a mismatch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101676&group_id=5470 From noreply@sourceforge.net Wed Sep 27 11:51:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 27 Sep 2000 03:51:13 -0700 Subject: [Patches] [Patch #101647] adds SSL server socket support to socketmodule.c Message-ID: <200009271051.DAA22158@bush.i.sourceforge.net> Patch #101647 has been updated. Project: Category: Modules Status: Postponed Summary: adds SSL server socket support to socketmodule.c Follow-Ups: Date: 2000-Sep-25 09:41 By: jhylton Comment: too late for 2.0 ------------------------------------------------------- Date: 2000-Sep-27 03:51 By: naris Comment: too late ? this patch solves world hunger and brings world peace! such a valuable patch, but i guess deadlines are deadlines :-( ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101647&group_id=5470 From noreply@sourceforge.net Wed Sep 27 11:51:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 27 Sep 2000 03:51:13 -0700 Subject: [Patches] [Patch #101647] adds SSL server socket support to socketmodule.c Message-ID: <200009271051.DAA22161@bush.i.sourceforge.net> Patch #101647 has been updated. Project: Category: Modules Status: Postponed Summary: adds SSL server socket support to socketmodule.c Follow-Ups: Date: 2000-Sep-25 09:41 By: jhylton Comment: too late for 2.0 ------------------------------------------------------- Date: 2000-Sep-27 03:51 By: naris Comment: too late ? this patch solves world hunger and brings world peace! such a valuable patch, but i guess deadlines are deadlines :-( ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101647&group_id=5470 From 96cedenio@eehs.surrey.sch.uk Wed Sep 27 12:35:31 2000 From: 96cedenio@eehs.surrey.sch.uk (96cedenio) Date: Wed, 27 Sep 2000 12:35:31 +0100 Subject: [Patches] hacking Message-ID: <000501c02877$10443a60$5904000a@lrc1> dear sir/madame, i hope you are fine. i need some information on hacking in to an aol email account or a hotmail email account. if you could help me with this please could you reply to me at fourplay85@hotmail.com i would be greatful if you could help me with this and also could please send me anything that would help me in becoming a hacker. thanks you for your co-operation. and i look forward to hearing from you soon. kind reguards JJ From noreply@sourceforge.net Wed Sep 27 13:09:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 27 Sep 2000 05:09:53 -0700 Subject: [Patches] [Patch #101679] Use full paths in _path_created cache Message-ID: <200009271209.FAA24860@bush.i.sourceforge.net> Patch #101679 has been updated. Project: Category: distutils Status: Open Summary: Use full paths in _path_created cache ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101679&group_id=5470 From noreply@sourceforge.net Wed Sep 27 13:10:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 27 Sep 2000 05:10:35 -0700 Subject: [Patches] [Patch #101679] Use full paths in _path_created cache Message-ID: <200009271210.FAA24877@bush.i.sourceforge.net> Patch #101679 has been updated. Project: Category: distutils Status: Open Summary: Use full paths in _path_created cache ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101679&group_id=5470 From noreply@sourceforge.net Wed Sep 27 20:24:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 27 Sep 2000 12:24:28 -0700 Subject: [Patches] [Patch #101682] poll fix for glibc 2.0.7 Message-ID: <200009271924.MAA09063@bush.i.sourceforge.net> Patch #101682 has been updated. Project: Category: library Status: Open Summary: poll fix for glibc 2.0.7 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101682&group_id=5470 From noreply@sourceforge.net Wed Sep 27 20:28:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 27 Sep 2000 12:28:38 -0700 Subject: [Patches] [Patch #101682] poll fix for glibc 2.0.7 Message-ID: <200009271928.MAA09243@bush.i.sourceforge.net> Patch #101682 has been updated. Project: Category: library Status: Open Summary: poll fix for glibc 2.0.7 Follow-Ups: Date: 2000-Sep-27 12:28 By: nascheme Comment: Debian 2.1 (glibc 2.0.7.19981211) poll.h does not contain defines for POLLRDNORM and friends. After this patch the selectmodule compiles but test_poll fails with: File "Lib/test/test_poll.py", line 77, in poll_unit_tests r = p.poll() error: (9, 'Bad file descriptor') The kernel is 2.0.38 if that makes a difference. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101682&group_id=5470 From noreply@sourceforge.net Thu Sep 28 03:23:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 27 Sep 2000 19:23:10 -0700 Subject: [Patches] [Patch #101679] Use full paths in _path_created cache Message-ID: <200009280223.TAA16854@delerium.i.sourceforge.net> Patch #101679 has been updated. Project: Category: distutils Status: Open Summary: Use full paths in _path_created cache Follow-Ups: Date: 2000-Sep-27 19:23 By: gward Comment: 1) coding standards? "foo(bar, baz)" not "foo( bar, baz )" please! 2) why not use os.path.abspath()? I have long since given up on Python 1.5.2 compatibility ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101679&group_id=5470 From noreply@sourceforge.net Thu Sep 28 13:25:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Sep 2000 05:25:32 -0700 Subject: [Patches] [Patch #101679] Use full paths in _path_created cache Message-ID: <200009281225.FAA12722@bush.i.sourceforge.net> Patch #101679 has been updated. Project: Category: distutils Status: Open Summary: Use full paths in _path_created cache Follow-Ups: Date: 2000-Sep-27 19:23 By: gward Comment: 1) coding standards? "foo(bar, baz)" not "foo( bar, baz )" please! 2) why not use os.path.abspath()? I have long since given up on Python 1.5.2 compatibility ------------------------------------------------------- Date: 2000-Sep-28 05:25 By: akuchling Comment: Patch changed to match coding standards, and to use os.path.abspath() as requested. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101679&group_id=5470 From noreply@sourceforge.net Thu Sep 28 20:16:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Sep 2000 12:16:34 -0700 Subject: [Patches] [Patch #101676] Detect conflicting Python DLL on module import under Windows Message-ID: <200009281916.MAA28592@bush.i.sourceforge.net> Patch #101676 has been updated. Project: Category: Windows Status: Open Summary: Detect conflicting Python DLL on module import under Windows Follow-Ups: Date: 2000-Sep-26 22:49 By: db3l Comment: This patch is an attempt to provide similar functionality to an earlier proposed patch (101651) but addressing Mark's concern about a process having two DLLs loaded explicitly. This patch parses the actual module import table after the module has been loaded into memory to determine which Python DLL (identified by a "python" prefix followed by just numbers) is loaded specifically by the module as opposed to just being in the process space, and compares that to the current Python version, complaining (and identifying the referenced DLL in the error) if there is a mismatch. ------------------------------------------------------- Date: 2000-Sep-28 12:16 By: fdrake Comment: Assigned to Mark Hammond since Tim's on vacation. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101676&group_id=5470 From noreply@sourceforge.net Thu Sep 28 22:35:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Sep 2000 14:35:53 -0700 Subject: [Patches] [Patch #101682] poll fix for glibc 2.0.7 Message-ID: <200009282135.OAA01990@bush.i.sourceforge.net> Patch #101682 has been updated. Project: Category: library Status: Closed Summary: poll fix for glibc 2.0.7 Follow-Ups: Date: 2000-Sep-27 12:28 By: nascheme Comment: Debian 2.1 (glibc 2.0.7.19981211) poll.h does not contain defines for POLLRDNORM and friends. After this patch the selectmodule compiles but test_poll fails with: File "Lib/test/test_poll.py", line 77, in poll_unit_tests r = p.poll() error: (9, 'Bad file descriptor') The kernel is 2.0.38 if that makes a difference. ------------------------------------------------------- Date: 2000-Sep-28 14:35 By: akuchling Comment: Accepted, modified to check for the existence of each #define individually. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101682&group_id=5470 From noreply@sourceforge.net Fri Sep 29 00:29:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Sep 2000 16:29:25 -0700 Subject: [Patches] [Patch #101699] GC fixes for malloc() == NULL Message-ID: <200009282329.QAA31268@delerium.i.sourceforge.net> Patch #101699 has been updated. Project: Category: core (C code) Status: Open Summary: GC fixes for malloc() == NULL ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101699&group_id=5470 From noreply@sourceforge.net Fri Sep 29 00:38:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Sep 2000 16:38:03 -0700 Subject: [Patches] [Patch #101699] GC fixes for malloc() == NULL Message-ID: <200009282338.QAA31508@delerium.i.sourceforge.net> Patch #101699 has been updated. Project: Category: core (C code) Status: Open Summary: GC fixes for malloc() == NULL Follow-Ups: Date: 2000-Sep-28 16:38 By: nascheme Comment: I would like some comments on this patch before I apply it. First, there must be a matching PyObject_GC_Fini() for every PyObject_GC_Init(). Second of all, between the Init and Fini calls, all pointers in the object struct followed by tp_recurse must be valid. GC can be triggered at wierd times. The problem with classobject.c was that if PyDict_New() failed, PyObject_DEL() was used to free the instance (which does not call PyObject_GC_Fini()). The problem with cPickle.c was that if PyDict_New() failed, Py_DECREF() was called to free the instance. Py_DECREF() will call instance_dealloc() which calls PyObject_GC_Fini(). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101699&group_id=5470 From noreply@sourceforge.net Fri Sep 29 12:38:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 29 Sep 2000 04:38:10 -0700 Subject: [Patches] [Patch #101702] Modify co_filename in frozen programs Message-ID: <200009291138.EAA24502@delerium.i.sourceforge.net> Patch #101702 has been updated. Project: Category: demos and tools Status: Open Summary: Modify co_filename in frozen programs ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101702&group_id=5470 From noreply@sourceforge.net Fri Sep 29 12:40:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 29 Sep 2000 04:40:00 -0700 Subject: [Patches] [Patch #101702] Modify co_filename in frozen programs Message-ID: <200009291140.EAA24615@delerium.i.sourceforge.net> Patch #101702 has been updated. Project: Category: demos and tools Status: Open Summary: Modify co_filename in frozen programs Follow-Ups: Date: 2000-Sep-29 04:39 By: lhudson Comment: A new feature for freeze. This patch was developed primarily to reduce the size of the frozen binary. It is particularly useful when freezing for 'small' platforms, such as Palm OS, where you really want to save that last miserable byte. A limitation of this patch is that it does not provide any feedback about the replacements being made. As the path matching is case-sensitive this may lead to unexpected behaviour for DOS and Windows people, eg > freeze.py -r C:\Python\Lib\=py\ goats.py should probably be: > freeze.py -r c:\python\lib\=py\ goats.py ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101702&group_id=5470 From noreply@sourceforge.net Fri Sep 29 12:40:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 29 Sep 2000 04:40:00 -0700 Subject: [Patches] [Patch #101702] Modify co_filename in frozen programs Message-ID: <200009291140.EAA24620@delerium.i.sourceforge.net> Patch #101702 has been updated. Project: Category: demos and tools Status: Open Summary: Modify co_filename in frozen programs Follow-Ups: Date: 2000-Sep-29 04:39 By: lhudson Comment: A new feature for freeze. This patch was developed primarily to reduce the size of the frozen binary. It is particularly useful when freezing for 'small' platforms, such as Palm OS, where you really want to save that last miserable byte. A limitation of this patch is that it does not provide any feedback about the replacements being made. As the path matching is case-sensitive this may lead to unexpected behaviour for DOS and Windows people, eg > freeze.py -r C:\Python\Lib\=py\ goats.py should probably be: > freeze.py -r c:\python\lib\=py\ goats.py ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101702&group_id=5470 From noreply@sourceforge.net Fri Sep 29 15:28:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 29 Sep 2000 07:28:48 -0700 Subject: [Patches] [Patch #101702] Modify co_filename in frozen programs Message-ID: <200009291428.HAA30882@delerium.i.sourceforge.net> Patch #101702 has been updated. Project: Category: demos and tools Status: Postponed Summary: Modify co_filename in frozen programs Follow-Ups: Date: 2000-Sep-29 04:39 By: lhudson Comment: A new feature for freeze. This patch was developed primarily to reduce the size of the frozen binary. It is particularly useful when freezing for 'small' platforms, such as Palm OS, where you really want to save that last miserable byte. A limitation of this patch is that it does not provide any feedback about the replacements being made. As the path matching is case-sensitive this may lead to unexpected behaviour for DOS and Windows people, eg > freeze.py -r C:\Python\Lib\=py\ goats.py should probably be: > freeze.py -r c:\python\lib\=py\ goats.py ------------------------------------------------------- Date: 2000-Sep-29 07:28 By: jhylton Comment: This sounds like a reasonable enough feature, but we are in feature freeze for Python 2.0. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101702&group_id=5470 From noreply@sourceforge.net Fri Sep 29 15:37:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 29 Sep 2000 07:37:56 -0700 Subject: [Patches] [Patch #101709] test_import to verify that .pyc files can be imported Message-ID: <200009291437.HAA31231@delerium.i.sourceforge.net> Patch #101709 has been updated. Project: Category: core (C code) Status: Open Summary: test_import to verify that .pyc files can be imported ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101709&group_id=5470 From noreply@sourceforge.net Fri Sep 29 15:38:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 29 Sep 2000 07:38:42 -0700 Subject: [Patches] [Patch #101709] test_import to verify that .pyc files can be imported Message-ID: <200009291438.HAA31249@delerium.i.sourceforge.net> Patch #101709 has been updated. Project: Category: core (C code) Status: Open Summary: test_import to verify that .pyc files can be imported Follow-Ups: Date: 2000-Sep-29 07:38 By: jhylton Comment: Will this detect the error in 2.0b2 and run on Windows? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101709&group_id=5470 From noreply@sourceforge.net Fri Sep 29 17:25:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 29 Sep 2000 09:25:13 -0700 Subject: [Patches] [Patch #101699] GC fixes for malloc() == NULL Message-ID: <200009291625.JAA11225@bush.i.sourceforge.net> Patch #101699 has been updated. Project: Category: core (C code) Status: Open Summary: GC fixes for malloc() == NULL Follow-Ups: Date: 2000-Sep-28 16:38 By: nascheme Comment: I would like some comments on this patch before I apply it. First, there must be a matching PyObject_GC_Fini() for every PyObject_GC_Init(). Second of all, between the Init and Fini calls, all pointers in the object struct followed by tp_recurse must be valid. GC can be triggered at wierd times. The problem with classobject.c was that if PyDict_New() failed, PyObject_DEL() was used to free the instance (which does not call PyObject_GC_Fini()). The problem with cPickle.c was that if PyDict_New() failed, Py_DECREF() was called to free the instance. Py_DECREF() will call instance_dealloc() which calls PyObject_GC_Fini(). ------------------------------------------------------- Date: 2000-Sep-29 09:25 By: fdrake Comment: Assigned to Jeremy since he knows the GC stuff pretty well. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101699&group_id=5470 From noreply@sourceforge.net Fri Sep 29 20:02:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 29 Sep 2000 12:02:15 -0700 Subject: [Patches] [Patch #101713] Free extension DLLs' handles during the Py_Finalize() Message-ID: <200009291902.MAA17167@bush.i.sourceforge.net> Patch #101713 has been updated. Project: Category: Windows Status: Open Summary: Free extension DLLs' handles during the Py_Finalize() ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101713&group_id=5470 From noreply@sourceforge.net Fri Sep 29 20:09:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 29 Sep 2000 12:09:36 -0700 Subject: [Patches] [Patch #101713] Free extension DLLs' handles during the Py_Finalize() Message-ID: <200009291909.MAA17396@bush.i.sourceforge.net> Patch #101713 has been updated. Project: Category: Windows Status: Open Summary: Free extension DLLs' handles during the Py_Finalize() Follow-Ups: Date: 2000-Sep-29 12:09 By: Markovitch Comment: This patch is intended to fix the following problem: Python on Windows never frees DLLs loaded as extension. Whenever it's not a big problem when the interpreter is being used in a standart way, it becomes THE problem (or even a disaster) when the interpreter DLL is dynamically initialized/finalized from one process many times during single run. Moreover, even in case of single initialization there is a trap - DLLs loaded by mistake are unloaded only then a process finishes (e.g. suppose there is a foo.dll in the current directory and foo.dll is NOT a Python extension; "import foo" ends up with error, but foo.dll will be anging in process' address space!) This patch 1) frees a DLL handle in case of it has no proper initialization funcion 2) registers in an internal array all handles of successfully loaded dynamic extensions 2) frees all registered handles during Py_Finalize() Yakov Markovitch, markovitch@iso.ru ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101713&group_id=5470 From noreply@sourceforge.net Fri Sep 29 20:09:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 29 Sep 2000 12:09:37 -0700 Subject: [Patches] [Patch #101713] Free extension DLLs' handles during the Py_Finalize() Message-ID: <200009291909.MAA17399@bush.i.sourceforge.net> Patch #101713 has been updated. Project: Category: Windows Status: Open Summary: Free extension DLLs' handles during the Py_Finalize() Follow-Ups: Date: 2000-Sep-29 12:09 By: Markovitch Comment: This patch is intended to fix the following problem: Python on Windows never frees DLLs loaded as extension. Whenever it's not a big problem when the interpreter is being used in a standart way, it becomes THE problem (or even a disaster) when the interpreter DLL is dynamically initialized/finalized from one process many times during single run. Moreover, even in case of single initialization there is a trap - DLLs loaded by mistake are unloaded only then a process finishes (e.g. suppose there is a foo.dll in the current directory and foo.dll is NOT a Python extension; "import foo" ends up with error, but foo.dll will be anging in process' address space!) This patch 1) frees a DLL handle in case of it has no proper initialization funcion 2) registers in an internal array all handles of successfully loaded dynamic extensions 2) frees all registered handles during Py_Finalize() Yakov Markovitch, markovitch@iso.ru ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101713&group_id=5470 From noreply@sourceforge.net Fri Sep 29 20:33:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 29 Sep 2000 12:33:04 -0700 Subject: [Patches] [Patch #101714] Missing `s' in format string Message-ID: <200009291933.MAA18350@bush.i.sourceforge.net> Patch #101714 has been updated. Project: Category: library Status: Open Summary: Missing `s' in format string ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101714&group_id=5470 From noreply@sourceforge.net Sat Sep 30 15:27:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 30 Sep 2000 07:27:16 -0700 Subject: [Patches] [Patch #101721] Fix for 115530: add closed attribute to cStringIO objects Message-ID: <200009301427.HAA24407@bush.i.sourceforge.net> Patch #101721 has been updated. Project: Category: None Status: Open Summary: Fix for 115530: add closed attribute to cStringIO objects ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101721&group_id=5470 From noreply@sourceforge.net Sat Sep 30 17:25:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 30 Sep 2000 09:25:56 -0700 Subject: [Patches] [Patch #101721] Fix for 115530/1: add closed attribute to cStringIO objects Message-ID: <200009301625.JAA19215@delerium.i.sourceforge.net> Patch #101721 has been updated. Project: Category: None Status: Open Summary: Fix for 115530/1: add closed attribute to cStringIO objects Follow-Ups: Date: 2000-Sep-30 09:25 By: loewis Comment: I have updated the patch to also fix 115530. The only remaining difference to StringIO is that cStringIO.readline does not support a maxsize argument. To add this parameter, the C API of cStringIO must be changed, and in turn cPickle. Is such a correction desirable? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101721&group_id=5470 From noreply@sourceforge.net Sat Sep 30 17:37:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 30 Sep 2000 09:37:16 -0700 Subject: [Patches] [Patch #101724] Fix for 115714: Don't rename Tkinter to Tk Message-ID: <200009301637.JAA19725@delerium.i.sourceforge.net> Patch #101724 has been updated. Project: Category: Tkinter Status: Open Summary: Fix for 115714: Don't rename Tkinter to Tk ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101724&group_id=5470 From noreply@sourceforge.net Sat Sep 30 18:52:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 30 Sep 2000 10:52:09 -0700 Subject: [Patches] [Patch #101679] Use full paths in _path_created cache Message-ID: <200009301752.KAA22431@delerium.i.sourceforge.net> Patch #101679 has been updated. Project: Category: distutils Status: Closed Summary: Use full paths in _path_created cache Follow-Ups: Date: 2000-Sep-27 19:23 By: gward Comment: 1) coding standards? "foo(bar, baz)" not "foo( bar, baz )" please! 2) why not use os.path.abspath()? I have long since given up on Python 1.5.2 compatibility ------------------------------------------------------- Date: 2000-Sep-28 05:25 By: akuchling Comment: Patch changed to match coding standards, and to use os.path.abspath() as requested. ------------------------------------------------------- Date: 2000-Sep-30 10:52 By: gward Comment: Typo in last comment -- I meant to say I have long since given up on *1.5.1* compatibility! Anyways, patch accepted and checked in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101679&group_id=5470