From noreply at sourceforge.net Mon Sep 1 01:05:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 1 03:05:39 2003 Subject: [Patches] [ python-Patches-798297 ] imaplib : Add support for the THREAD command Message-ID: Patches item #798297, was opened at 2003-09-01 00:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798297&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Yves Dionne (dionney) Assigned to: Nobody/Anonymous (nobody) Summary: imaplib : Add support for the THREAD command Initial Comment: This patch add support for the THREAD IMAP command to the imaplib module. It basicly is a copy of the sort() procedure :) The THREAD command is still not a IETF RFC, but many IMAP server implement it. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-01 09:05 Message: Logged In: YES user_id=21627 Can you please include a patch to Doc/lib/libimaplib.tex as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798297&group_id=5470 From noreply at sourceforge.net Mon Sep 1 02:45:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 1 04:45:16 2003 Subject: [Patches] [ python-Patches-797180 ] Bug 792656: slicing explained Message-ID: Patches item #797180, was opened at 2003-08-29 12:55 Message generated for change (Comment added) made by tzot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=797180&group_id=5470 Category: Documentation Group: Python 2.4 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: Bug 792656: slicing explained Initial Comment: Based on what the bug 792656 suggested. ---------------------------------------------------------------------- >Comment By: Christos Georgiou (tzot) Date: 2003-09-01 11:45 Message: Logged In: YES user_id=539787 If there was a "Check to Upload and Attach a File" option in the bug section (like it used to), I would gladly post there the patch; but I don't see one anymore, logged in as tzot. Perhaps somebody has set the permissions so that patches of lay-developers :) go to patches and not to the bugs section... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-31 02:36 Message: Logged In: YES user_id=80475 Accepted with minor revisions: * Moved parenthetical to separate sentence * \code{k} should have been \var{k} * Fixed existing misspelling of 'ommitted' See Doc/lib/libstdtypes.tex 1.131 and 1.129.8.2. Thanks for the patch. In the future, it would be helpful to me if you attached the patch to the original bug report. Feel free to assign to me for review. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=797180&group_id=5470 From noreply at sourceforge.net Mon Sep 1 04:31:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 1 06:31:22 2003 Subject: [Patches] [ python-Patches-798467 ] Update docstring of has_key for bool changes Message-ID: Patches item #798467, was opened at 2003-09-01 19:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798467&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: Update docstring of has_key for bool changes Initial Comment: The docstring of has_key is not updated. It now returns boolean values after Python 2.3. I've attached a patch file to reflect this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798467&group_id=5470 From noreply at sourceforge.net Mon Sep 1 06:13:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 1 08:13:32 2003 Subject: [Patches] [ python-Patches-788404 ] ignore "b" and "t" mode modifiers in posix_popen Message-ID: Patches item #788404, was opened at 2003-08-13 17:53 Message generated for change (Comment added) made by gaul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788404&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Gaul (gaul) Assigned to: Nobody/Anonymous (nobody) Summary: ignore "b" and "t" mode modifiers in posix_popen Initial Comment: Fixes bug 703198. This patch removes any "b" or "t" modifiers, which have meaning in Windows (binary and text modes, respectively), but not in POSIX. This allows users to write portable code between Windows and POSIX when working on binary data in pipes: os.popen(cmd, 'rb'). ---------------------------------------------------------------------- >Comment By: Andrew Gaul (gaul) Date: 2003-09-01 07:13 Message: Logged In: YES user_id=139865 *puzzles over why patch is so backward* Yes, it modifies an immutable object - double plus ungood. Attached is a simpler patch which does the right thing. Sorry, I do not know what was going through my head at the time. My best guess was that I thought that mode was a safe, mutable copy of the immutable Python string and I wanted to allow modes like "br", which the MSDN docs actually say are invalid ('b' and 't' modifiers must be appended). Note that the behaviour of POSIX posix_popen in this patch differs from Windows posix_popen, as the latter allows treats "rw", "r+", and "rr" as "r". In all three cases, POSIX systems throw "OSError: [Errno 22] Invalid argument" at pipe creation. In the case of "rw", Windows systems throw "IOError: [Errno 9] Bad file descriptor" when the read-only pipe is first written to. Ideally, Windows posix_popen should be modified to the new POSIX behaviour to give earlier error reporting. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-31 11:42 Message: Logged In: YES user_id=21627 Maybe I'm mistaken: Does this patch really modify the string object that is being passed? This would not be good: strings are immutable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788404&group_id=5470 From noreply at sourceforge.net Mon Sep 1 06:48:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 1 08:48:14 2003 Subject: [Patches] [ python-Patches-798534 ] Windows os.popen needlessly gets a reference to tuple () Message-ID: Patches item #798534, was opened at 2003-09-01 07:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798534&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Gaul (gaul) Assigned to: Nobody/Anonymous (nobody) Summary: Windows os.popen needlessly gets a reference to tuple () Initial Comment: Windows os.popen creates a zero length tuple and does not use or destroy it. Warning: attached patch has not been tested! I do not have a Windows development environment. Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os, sys >>> sys.getrefcount(()) 440 >>> p = os.popen('dir') >>> sys.getrefcount(()) 441 >>> p = os.popen('dir') >>> sys.getrefcount(()) 442 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798534&group_id=5470 From noreply at sourceforge.net Mon Sep 1 08:15:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 1 10:16:07 2003 Subject: [Patches] [ python-Patches-794400 ] startup file compiler flags Message-ID: Patches item #794400, was opened at 2003-08-24 19:15 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=794400&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eric Tiedemann (est) Assigned to: Nobody/Anonymous (nobody) Summary: startup file compiler flags Initial Comment: Allow the startup file to modify the compiler flags. This allows you, for example, to have true division automatically in interactive mode. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2003-09-01 09:15 Message: Logged In: YES user_id=2772 Works for me. It's a simple change, even though some code was moved out of line into a separate static function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=794400&group_id=5470 From noreply at sourceforge.net Mon Sep 1 10:11:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 1 12:12:11 2003 Subject: [Patches] [ python-Patches-798638 ] Improve "veryhigh.tex" API docs Message-ID: Patches item #798638, was opened at 2003-09-01 11:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798638&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Nobody/Anonymous (nobody) Summary: Improve "veryhigh.tex" API docs Initial Comment: Many variant versions of functions were not documented in this chapter, and the PyCompilerFlags structure was not documented at all. This patch fixes that. It adds documentation for: +\begin{cfuncdesc}{int}{PyRun_AnyFileFlags}{FILE *fp, const char *filename, +\begin{cfuncdesc}{int}{PyRun_AnyFileEx}{FILE *fp, const char *filename, +\begin{cfuncdesc}{int}{PyRun_AnyFileExFlags}{FILE *fp, const char *filename, +\begin{cfuncdesc}{int}{PyRun_SimpleStringFlags}{const char *command, +\begin{cfuncdesc}{int}{PyRun_SimpleFileFlags}{FILE *fp, const char *filename, +\begin{cfuncdesc}{int}{PyRun_SimpleFileEx}{FILE *fp, const char *filename, +\begin{cfuncdesc}{int}{PyRun_SimpleFileExFlags}{FILE *fp, const char *filename, +\begin{cfuncdesc}{int}{PyRun_InteractiveOneFlags}{FILE *fp, +\begin{cfuncdesc}{int}{PyRun_InteractiveLoopFlags}{FILE *fp, +\begin{cfuncdesc}{struct _node*}{PyParser_SimpleParseStringFlags}{ +\begin{cfuncdesc}{struct _node*}{PyParser_SimpleParseStringFlagsFilename}{ +\begin{cfuncdesc}{struct _node*}{PyParser_SimpleParseFileFlags}{FILE *fp, +\begin{cfuncdesc}{PyObject*}{PyRun_StringFlags}{const char *str, int start, +\begin{cfuncdesc}{PyObject*}{PyRun_FileEx}{FILE *fp, const char *filename, +\begin{cfuncdesc}{PyObject*}{PyRun_FileFlags}{FILE *fp, const char *filename, +\begin{cfuncdesc}{PyObject*}{PyRun_FileExFlags}{FILE *fp, const char *filename, +\begin{cfuncdesc}{PyObject*}{Py_CompileStringFlags}{char *str, +\begin{ctypedesc}[PyCompilerFlags]{struct PyCompilerFlags} +\begin{cvardesc}{int}{CO_FUTURE_DIVISION} This patch also reflects the "const"ness of arguments to these functions. latex seemed to process the modified documentation just fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798638&group_id=5470 From noreply at sourceforge.net Mon Sep 1 10:25:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 1 12:25:40 2003 Subject: [Patches] [ python-Patches-793070 ] Add --remove-source option to setup.py Message-ID: Patches item #793070, was opened at 2003-08-22 12:10 Message generated for change (Comment added) made by davidfraser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793070&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Fraser (davidfraser) Assigned to: Nobody/Anonymous (nobody) Summary: Add --remove-source option to setup.py Initial Comment: For distributing non-opensource software, it is helpful to just distribute the .pyc/.pyo files and not the original .py files. The reverse (just distributing .py files) is possible through the --no-target-compile and --no-target-optimize switches to the distutils bdist command. We have added a --remove-source option which goes through and deletes all the source files from the build directory. This has been tested and works smoothly with Python 2.2.3 and seems to apply cleanly to Python 2.3 ---------------------------------------------------------------------- >Comment By: David Fraser (davidfraser) Date: 2003-09-01 18:25 Message: Logged In: YES user_id=221678 As far as I understand, the compiled files are generated in the build dir from the source files which have been copied there. Simply removing the source files afterwards means we don't have to make any changes to the whole way distutils operates. Also, we don't want to compile in-tree and then move the files as that might create confusing results when compiling for multiple versions of Python. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-31 18:18 Message: Logged In: YES user_id=21627 Wouldn't it be better not to copy the files into the build dir in the first place? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793070&group_id=5470 From noreply at sourceforge.net Mon Sep 1 11:21:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 1 13:21:57 2003 Subject: [Patches] [ python-Patches-798297 ] imaplib : Add support for the THREAD command Message-ID: Patches item #798297, was opened at 2003-08-31 18:36 Message generated for change (Comment added) made by dionney You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798297&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Yves Dionne (dionney) Assigned to: Nobody/Anonymous (nobody) Summary: imaplib : Add support for the THREAD command Initial Comment: This patch add support for the THREAD IMAP command to the imaplib module. It basicly is a copy of the sort() procedure :) The THREAD command is still not a IETF RFC, but many IMAP server implement it. ---------------------------------------------------------------------- >Comment By: Yves Dionne (dionney) Date: 2003-09-01 13:21 Message: Logged In: YES user_id=11733 I've made a new patch that include mods to Doc/lib/libimaplib.tex, as requested. Also, the new patch was made against Python 2.3; the old one was against 2.2.3. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-01 03:05 Message: Logged In: YES user_id=21627 Can you please include a patch to Doc/lib/libimaplib.tex as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798297&group_id=5470 From noreply at sourceforge.net Mon Sep 1 16:15:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 1 18:15:30 2003 Subject: [Patches] [ python-Patches-798467 ] Update docstring of has_key for bool changes Message-ID: Patches item #798467, was opened at 2003-09-01 05:31 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798467&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: Update docstring of has_key for bool changes Initial Comment: The docstring of has_key is not updated. It now returns boolean values after Python 2.3. I've attached a patch file to reflect this. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 17:15 Message: Logged In: YES user_id=80475 Applied as: Objects/descrobject.c 2.36 and 2.35.10.1 Objects/dictobject.c 2.147 and 2.146.8.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798467&group_id=5470 From noreply at sourceforge.net Mon Sep 1 16:20:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 1 18:20:36 2003 Subject: [Patches] [ python-Patches-798638 ] Improve "veryhigh.tex" API docs Message-ID: Patches item #798638, was opened at 2003-09-01 11:11 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798638&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Improve "veryhigh.tex" API docs Initial Comment: Many variant versions of functions were not documented in this chapter, and the PyCompilerFlags structure was not documented at all. This patch fixes that. It adds documentation for: +\begin{cfuncdesc}{int}{PyRun_AnyFileFlags}{FILE *fp, const char *filename, +\begin{cfuncdesc}{int}{PyRun_AnyFileEx}{FILE *fp, const char *filename, +\begin{cfuncdesc}{int}{PyRun_AnyFileExFlags}{FILE *fp, const char *filename, +\begin{cfuncdesc}{int}{PyRun_SimpleStringFlags}{const char *command, +\begin{cfuncdesc}{int}{PyRun_SimpleFileFlags}{FILE *fp, const char *filename, +\begin{cfuncdesc}{int}{PyRun_SimpleFileEx}{FILE *fp, const char *filename, +\begin{cfuncdesc}{int}{PyRun_SimpleFileExFlags}{FILE *fp, const char *filename, +\begin{cfuncdesc}{int}{PyRun_InteractiveOneFlags}{FILE *fp, +\begin{cfuncdesc}{int}{PyRun_InteractiveLoopFlags}{FILE *fp, +\begin{cfuncdesc}{struct _node*}{PyParser_SimpleParseStringFlags}{ +\begin{cfuncdesc}{struct _node*}{PyParser_SimpleParseStringFlagsFilename}{ +\begin{cfuncdesc}{struct _node*}{PyParser_SimpleParseFileFlags}{FILE *fp, +\begin{cfuncdesc}{PyObject*}{PyRun_StringFlags}{const char *str, int start, +\begin{cfuncdesc}{PyObject*}{PyRun_FileEx}{FILE *fp, const char *filename, +\begin{cfuncdesc}{PyObject*}{PyRun_FileFlags}{FILE *fp, const char *filename, +\begin{cfuncdesc}{PyObject*}{PyRun_FileExFlags}{FILE *fp, const char *filename, +\begin{cfuncdesc}{PyObject*}{Py_CompileStringFlags}{char *str, +\begin{ctypedesc}[PyCompilerFlags]{struct PyCompilerFlags} +\begin{cvardesc}{int}{CO_FUTURE_DIVISION} This patch also reflects the "const"ness of arguments to these functions. latex seemed to process the modified documentation just fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798638&group_id=5470 From noreply at sourceforge.net Mon Sep 1 16:37:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 1 18:38:02 2003 Subject: [Patches] [ python-Patches-798534 ] Windows os.popen needlessly gets a reference to tuple () Message-ID: Patches item #798534, was opened at 2003-09-01 07:48 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798534&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Andrew Gaul (gaul) Assigned to: Nobody/Anonymous (nobody) Summary: Windows os.popen needlessly gets a reference to tuple () Initial Comment: Windows os.popen creates a zero length tuple and does not use or destroy it. Warning: attached patch has not been tested! I do not have a Windows development environment. Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os, sys >>> sys.getrefcount(()) 440 >>> p = os.popen('dir') >>> sys.getrefcount(()) 441 >>> p = os.popen('dir') >>> sys.getrefcount(()) 442 ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 17:37 Message: Logged In: YES user_id=80475 Applied as: Modules/posixmodule.c 2.302 and 2.300.8.2 Thanks for the patch :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798534&group_id=5470 From noreply at sourceforge.net Mon Sep 1 16:52:37 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 1 18:52:41 2003 Subject: [Patches] [ python-Patches-791153 ] inconsistency with implementation(logging) Message-ID: Patches item #791153, was opened at 2003-08-19 06:19 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=791153&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: inconsistency with implementation(logging) Initial Comment: logging module's Handler object uses creaLock() to serialize access to an I/O mechanism, not getLock(). This is inconsistent with the implementation. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 17:52 Message: Logged In: YES user_id=80475 Applied as: Doc/lib/liblogging.tex 1.13 and 1.12.8.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=791153&group_id=5470 From noreply at sourceforge.net Mon Sep 1 16:56:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 1 18:56:35 2003 Subject: [Patches] [ python-Patches-780595 ] Fix zip file header format in zipfile.py Message-ID: Patches item #780595, was opened at 2003-07-30 18:58 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=780595&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: John M. Baughman (scuzball1) >Assigned to: Greg Ward (gward) Summary: Fix zip file header format in zipfile.py Initial Comment: The zip file header unpack format uses signed longs for those values. For the readfile function to work with very large files (2GB+ in my case) it needs to use unsigned longs. In the case of these files, the readfile code would break with a memory error when trying to buffer backwards in memory since the value is converted to a signed long producing a negative value. This patch converts the header unpack format to use unsigned longs. -John M. Baughman ---------------------------------------------------------------------- Comment By: John M. Baughman (scuzball1) Date: 2003-07-31 10:44 Message: Logged In: YES user_id=834241 My bad, this patch is for zipfile.py. Got in a slight hurry last night and didn't complete the description well enough. -John M. Baughman ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=780595&group_id=5470 From noreply at sourceforge.net Mon Sep 1 17:07:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 1 19:07:39 2003 Subject: [Patches] [ python-Patches-774414 ] Add a stream type and a merge type to itertoolsmodule.c Message-ID: Patches item #774414, was opened at 2003-07-19 19:53 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=774414&group_id=5470 Category: Modules Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Ben Wolfson (rumjuggler) Assigned to: Nobody/Anonymous (nobody) Summary: Add a stream type and a merge type to itertoolsmodule.c Initial Comment: This patch adds a stream type to itertoolsmodule.c, which provides a way to cache results from a generator. This is useful if you want to iterate over the generator more than once. It also lets potentially infinite generators simulate lists/tuples; stream(some_generator())[10] produces the first 11 values from the generator and returns the last one, but doesn't produce any more. The other type added is useable to merge the output of two (sorted) iterables into one iterable. I assume documentation would also need to be updated if this patch gets accepted, but since I imagine that won't be an open-and-shut case I haven't written any yet. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 18:07 Message: Logged In: YES user_id=80475 The use cases for iterating more than once are better served by iterator splitting. See http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/2 13027 . For the given example, stream(some_generator())[10], the need is already met by islice(a, 10, 11).next(). There may yet be an opportunity to develop a lazylist type that has an underlying iterator. It would be belong outside the scope of itertools and would need to have demonstrated its usefulness by being released into the wild for while. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-19 20:56 Message: Logged In: YES user_id=80475 Originally, I looked at implementing all of itertools as a single object supporting various methods but rejected it after working through the use cases. It may be time to take another look. At first glance, this object does not fit well with other itertools: * it returns an object supporting more than __iter__ and next * it consumes memory (other itertools except for cycle do not require auxiliary storage) * it does not support a functional style (to take advantage of the cache, a cache object needs to be created and further accesses go from there). The one example you supplied is better accomplished with islice() -- see the documentation example for nth(). * it doesn't play nice with other itertools which would need to be modified to take advantage of the cache: s=stream (some_gen()). I can see some need for caching behavior but would like to see compelling use cases that cannot easily be met with list () and islice(). Create a few examples like the ones in the itertools documentation. These will demonstrate the use cases and show that the new function can play nicely with the other building blocks. Try implementing window() with the stream tool. Also, I'm concerned about the len() method on a potentially infinite generator. See if you can find a better name for it than stream(). Ideally, the name should suggest caching, sequence-like behavior, and lazy evaluation. Try coding a pure python version and submitting it to the newgroup to build support for the idea, see if other's can refine the idea, and to tease out use cases. The merge() function is not sufficiently general purpose to warrant inclusion in itertools. Also, it would be best to allow custom comparison so as not to lock in ascending order behavior. Your assumption on documentation is correct. Also you would need unittests, examples, and a pure-python version. Overall, the patch looks nicely done. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=774414&group_id=5470 From noreply at sourceforge.net Mon Sep 1 17:29:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 1 19:29:11 2003 Subject: [Patches] [ python-Patches-790443 ] add SafeConfigParser to __all__ Message-ID: Patches item #790443, was opened at 2003-08-18 04:59 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790443&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: add SafeConfigParser to __all__ Initial Comment: Starting with Python 2.3, SafeConfigParser is preferred over ConfigParser. http://www.python.org/doc/current/lib/module- ConfigParser.html#l2h-1231 So why not add SafeConfigParser to __all__? There's another fix. RawConfigParser._read has a strange code. # allow empty values if optval == '""': optval = '' This if-condition is evaluated true if and only if name=value pair is as follows: name = "" and this code converts the value to an empty string, ''. '""' is a string of two double quotes and '' is an empty string. They're totally different. I think this part is redundant. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 18:29 Message: Logged In: YES user_id=80475 The double quoting part seems fine to me. If it is driving you nuts, re-open this patch and assign to Barry Warsaw who wrote those lines. The part about SafeConfigParser is reasonable. Am updating the files now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790443&group_id=5470 From noreply at sourceforge.net Mon Sep 1 17:38:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 1 19:38:54 2003 Subject: [Patches] [ python-Patches-774221 ] 2.3c1: zipfile.py confused by garbage at the very end of zip Message-ID: Patches item #774221, was opened at 2003-07-19 10:00 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=774221&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nikolai Saoukh (nms) >Assigned to: Greg Ward (gward) Summary: 2.3c1: zipfile.py confused by garbage at the very end of zip Initial Comment: Some zip files can contain garbage past the End of Central Directory. _EndRecData() treat it as comment, thus failing sanity check for comment length. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=774221&group_id=5470 From noreply at sourceforge.net Mon Sep 1 19:53:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 1 21:54:01 2003 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 05:45 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 20:53 Message: Logged In: YES user_id=80475 Applied as: Lib/test/test_slice.py 1.5. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-31 18:52 Message: Logged In: YES user_id=80475 Looks good. I added a couple of minor tests. Revised patch attached. Okay to apply. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-31 14:49 Message: Logged In: YES user_id=89016 Thanks! Here's another one: test_slice.py ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 18:04 Message: Logged In: YES user_id=80475 Done. See: Lib/test/test_longexp.py 1.9; previous revision: 1.8 Lib/test/test_pep263.py 1.3; previous revision: 1.2 Lib/test/test_sets.py 1.27; previous revision: 1.26 Lib/test/test_structseq.py 1.5; previous revision: 1.4 Lib/test/output/test_longexp delete; previous revision: 1.3 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 12:10 Message: Logged In: YES user_id=80475 Will do! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-30 12:06 Message: Logged In: YES user_id=89016 Here's test_structse.py converted with a few additional tests. If all three scripts are OK, could you check them in Raymond, as I'll be on vacation for three weeks? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-09 10:47 Message: Logged In: YES user_id=89016 Here are two simple ones: test_pep263 and test_longexp. I can't think of any additional tests to add. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-23 08:38 Message: Logged In: YES user_id=80475 Fixed Walter's review comments and committed as Lib/test/test_compile.py 1.19 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-23 06:49 Message: Logged In: YES user_id=89016 Are you sure, that the code path is the same in the new test_argument_handling() as in the old test? I.e. is "eval('lambda a,a: 0')" the same as "exec 'def f(a, a): pass'"? The print statement in test_float_literals should be changed to a comment. Should the imports in test_unary_minus() be moved to the start of the script? Otherwise the test looks (and runs) OK. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-20 14:26 Message: Logged In: YES user_id=80475 Here's one for you: test_compile.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-19 04:46 Message: Logged In: YES user_id=89016 Maybe test_types.py should be split into several scripts: test_dict, test_tuple, test_list, test_int, test_long etc. Some of them already exist (like test_long), some don't. The constructor tests from test_builtin should probably be moved to the new test scripts as well. Furthermore we should try to share as much testing functionality as possible (e.g. between test_int and test_long, or between test_list and test_userlist) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 14:48 Message: Logged In: YES user_id=80475 Great! Can I suggest that test_types.py be next. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-18 09:27 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_builtin.py 1.21 Lib/test/test_complex.py 1.10 (I've moved the constructor tests from test_builtin to test_complex) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-17 18:49 Message: Logged In: YES user_id=80475 I added a few tests. If they are fine with you, go ahead and commit. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 16:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 07:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 16:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 14:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 14:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 14:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 14:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 13:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 13:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 11:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 10:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 10:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 07:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 12:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 11:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 10:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 08:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 18:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 22:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-17 21:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-17 20:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-17 19:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 18:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply at sourceforge.net Mon Sep 1 20:11:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 1 22:12:08 2003 Subject: [Patches] [ python-Patches-798269 ] bug fix for doctest (sf bug id: 798254) Message-ID: Patches item #798269, was opened at 2003-08-31 16:11 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798269&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Raymond Hettinger (rhettinger) Summary: bug fix for doctest (sf bug id: 798254) Initial Comment: See bug report #798254 for description of the bug. This patch allows methods borrowed from other classes to appear in the class dictionary without breaking doctest. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 21:11 Message: Logged In: YES user_id=80475 Applied as: Lib/doctest.py 1.30.6.1 and 1.31 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798269&group_id=5470 From noreply at sourceforge.net Mon Sep 1 20:19:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 1 22:19:57 2003 Subject: [Patches] [ python-Patches-797180 ] Bug 792656: slicing explained Message-ID: Patches item #797180, was opened at 2003-08-29 04:55 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=797180&group_id=5470 Category: Documentation Group: Python 2.4 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: Bug 792656: slicing explained Initial Comment: Based on what the bug 792656 suggested. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 21:19 Message: Logged In: YES user_id=80475 Hmm, I have no idea why the Attach File option was taken out. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-09-01 03:45 Message: Logged In: YES user_id=539787 If there was a "Check to Upload and Attach a File" option in the bug section (like it used to), I would gladly post there the patch; but I don't see one anymore, logged in as tzot. Perhaps somebody has set the permissions so that patches of lay-developers :) go to patches and not to the bugs section... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 18:36 Message: Logged In: YES user_id=80475 Accepted with minor revisions: * Moved parenthetical to separate sentence * \code{k} should have been \var{k} * Fixed existing misspelling of 'ommitted' See Doc/lib/libstdtypes.tex 1.131 and 1.129.8.2. Thanks for the patch. In the future, it would be helpful to me if you attached the patch to the original bug report. Feel free to assign to me for review. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=797180&group_id=5470 From noreply at sourceforge.net Mon Sep 1 20:34:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 1 22:34:53 2003 Subject: [Patches] [ python-Patches-798255 ] Document httplib.HTTPResponse.read "amt" argument Message-ID: Patches item #798255, was opened at 2003-08-31 15:32 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798255&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Raymond Hettinger (rhettinger) Summary: Document httplib.HTTPResponse.read "amt" argument Initial Comment: This method takes an optional arg, similar to file.read. Document it. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 21:34 Message: Logged In: YES user_id=80475 Applied as: Doc/lib/libhttplib.tex 1.35 and 1.34.10.1 Thanks for the patch :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798255&group_id=5470 From noreply at sourceforge.net Tue Sep 2 01:05:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 2 03:05:51 2003 Subject: [Patches] [ python-Patches-663482 ] 658254: accept None for time.ctime() and friends Message-ID: Patches item #663482, was opened at 2003-01-06 22:42 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=663482&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Christopher Blunck (blunck2) >Assigned to: Raymond Hettinger (rhettinger) Summary: 658254: accept None for time.ctime() and friends Initial Comment: ctime(), gmtime(), and localtime() now support None and treat it as tho you passed no arguments at all. i am new to patching for py and am not sure if there are unit tests i should update. please advise... ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-06 15:38 Message: Logged In: YES user_id=357491 What do people think of this functionality? I personally don't see a need for it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 17:33 Message: Logged In: YES user_id=33168 There don't appear to be any direct tests, but it would still be nice to call the functions and verify they work ok. You could compare that abs(ctime() - ctime(None)) < .5, for example. Look in Lib/test/test_time.py. Also, the docs need to be updated, see Doc/lib/libtime.tex. That should be updated, ie change \optional(secs) with \optional{secs\code{ = None}}. Also, an entry in Misc/NEWS should be added since this is an API change. There is no attached file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=663482&group_id=5470 From noreply at sourceforge.net Tue Sep 2 05:52:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 2 07:53:06 2003 Subject: [Patches] [ python-Patches-759208 ] curses has_key emulation fix Message-ID: Patches item #759208, was opened at 2003-06-23 09:14 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=759208&group_id=5470 Category: Library (Lib) Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Mats Wichmann (mwichmann) Assigned to: A.M. Kuchling (akuchling) Summary: curses has_key emulation fix Initial Comment: curses/has_key.py provides emulation for the ncurses has_key routine for those that don't have it. Out-of- range has_key requests cause a KeyError exception. Note that the curses regression test makes such a request! The attached trivial patch makes has_key more robust. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-09-02 07:52 Message: Logged In: YES user_id=11375 Checked in as rev. 1.3 of has_key.py; thanks! ---------------------------------------------------------------------- Comment By: Mats Wichmann (mwichmann) Date: 2003-06-30 23:09 Message: Logged In: YES user_id=53605 I certainly have no objection to the logic change, but don't have time right now to gen a new patch. Should be an easy manual change. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-30 12:11 Message: Logged In: YES user_id=6380 Looks harmless to me. Somebody please check this in. (Personally, I'd change the logic around so it reads: if not _capability_names.has_key(ch): return 0 ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=759208&group_id=5470 From noreply at sourceforge.net Tue Sep 2 09:15:58 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 2 11:16:03 2003 Subject: [Patches] [ python-Patches-799190 ] Fix ord() documentation Message-ID: Patches item #799190, was opened at 2003-09-02 10:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=799190&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Nobody/Anonymous (nobody) Summary: Fix ord() documentation Initial Comment: The online version of the documentation for ord() (currently http://python.org/doc/current/lib/built-in-funcs.html#l2h-55) has a line-break where a backslash should be ('\u2020'). This patch changes \ to \e, which follows practice elsewhere in that file (when representing '\n', for instance) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=799190&group_id=5470 From noreply at sourceforge.net Tue Sep 2 09:16:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 2 11:16:06 2003 Subject: [Patches] [ python-Patches-799191 ] Fix ord() documentation Message-ID: Patches item #799191, was opened at 2003-09-02 10:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=799191&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Nobody/Anonymous (nobody) Summary: Fix ord() documentation Initial Comment: The online version of the documentation for ord() (currently http://python.org/doc/current/lib/built-in-funcs.html#l2h-55) has a line-break where a backslash should be ('\u2020'). This patch changes \ to \e, which follows practice elsewhere in that file (when representing '\n', for instance) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=799191&group_id=5470 From noreply at sourceforge.net Tue Sep 2 09:17:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 2 11:17:25 2003 Subject: [Patches] [ python-Patches-799190 ] Fix ord() documentation Message-ID: Patches item #799190, was opened at 2003-09-02 10:15 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=799190&group_id=5470 Category: None Group: None >Status: Deleted >Resolution: Duplicate Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Nobody/Anonymous (nobody) Summary: Fix ord() documentation Initial Comment: The online version of the documentation for ord() (currently http://python.org/doc/current/lib/built-in-funcs.html#l2h-55) has a line-break where a backslash should be ('\u2020'). This patch changes \ to \e, which follows practice elsewhere in that file (when representing '\n', for instance) ---------------------------------------------------------------------- >Comment By: Jeff Epler (jepler) Date: 2003-09-02 10:17 Message: Logged In: YES user_id=2772 accidentally double-submitted ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=799190&group_id=5470 From noreply at sourceforge.net Tue Sep 2 14:14:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 2 16:14:12 2003 Subject: [Patches] [ python-Patches-799367 ] effect/affect error in libdatetime.tex Message-ID: Patches item #799367, was opened at 2003-09-02 14:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=799367&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven Taschuk (staschuk) Assigned to: Nobody/Anonymous (nobody) Summary: effect/affect error in libdatetime.tex Initial Comment: See the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=799367&group_id=5470 From noreply at sourceforge.net Tue Sep 2 14:17:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 2 16:18:09 2003 Subject: [Patches] [ python-Patches-727789 ] Editing of __str__ and __repr__ docs Message-ID: Patches item #727789, was opened at 2003-04-25 16:25 Message generated for change (Settings changed) made by staschuk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=727789&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Steven Taschuk (staschuk) Assigned to: Nobody/Anonymous (nobody) Summary: Editing of __str__ and __repr__ docs Initial Comment: A recent thread in comp.lang.python [1] suggests that there is some question whether the existing docs for the __str__ and __repr__ methods is clear, and whether what it says is good in the first place. The patch shows proposed changes based on the discussions in that thread. The new text treats __repr__ as a programmer-centric stringification (with eval(repr(x)) == x as a possibility, rather than a principle), and __str__ as a more general-purpose stringification-as-appropriate- to-the-object. [1] http://groups.google.com/groups?th=24b817d49ec3a59b ---------------------------------------------------------------------- >Comment By: Steven Taschuk (staschuk) Date: 2003-09-02 14:17 Message: Logged In: YES user_id=666873 I'll close it; I have no revision coming. Someone more motivated than I am can take the discussion to c.l.py if desired. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-26 23:15 Message: Logged In: YES user_id=80475 Can we close this patch or is a revision forthcoming? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-08 19:07 Message: Logged In: YES user_id=80475 Consider taking this back to the newsgroup to tease out some wording that everyone finds more palatable. The verbiage should be terse, factual, and general without being overly abstract or preachy. The most recent suggestion (below) is not one I would approve. The circularity and indirectness make the docs unhelpful, hard to read, and uninformative. Brett's suggestion is close to the mark. ---------------------------------------------------------------------- Comment By: Donn Cave (donnc) Date: 2003-07-08 18:04 Message: Logged In: YES user_id=42839 In __str__, I would replace the whole commentary paragraph with "This string value is the result of converting the object data to string type, for use in applications that require a string and don't care about the original object per se." ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-08 18:20 Message: Logged In: YES user_id=357491 I agree with Raymond that it seems "wordy". For instance, the first changed paragraph is basically just trying to say "__repr__ should return something that can be past to 'eval' to return return the same object. If this is not possible then make its output useful to the programmer." Don't need to go on about it needing to be a "valid Python expression" and such. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-28 22:52 Message: Logged In: YES user_id=80475 The patch looks technically correct. It is wordy and I liked the original better, but clarity is more important. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=727789&group_id=5470 From noreply at sourceforge.net Tue Sep 2 18:25:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 2 20:25:43 2003 Subject: [Patches] [ python-Patches-756253 ] itertools roundrobin() Message-ID: Patches item #756253, was opened at 2003-06-17 17:35 Message generated for change (Comment added) made by jackdied You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756253&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jack Diederich (jackdied) Assigned to: Raymond Hettinger (rhettinger) >Summary: itertools roundrobin() Initial Comment: a patch to add the roundrobin() and window() objects to the itertools module. Hettinger has already seen the implementation of roundrobin, but not window. test_itertools.py in a seperate patch ---------------------------------------------------------------------- >Comment By: Jack Diederich (jackdied) Date: 2003-09-02 20:25 Message: Logged In: YES user_id=591932 The newest triplet of module/test/documentation incorporate your change suggestions. That includes the removal of the window() stuff, so these only contain roundrobin() related patches. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-27 01:13 Message: Logged In: YES user_id=80475 Jack, are you still working on this one? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-01 01:12 Message: Logged In: YES user_id=80475 Great. I look forward to it. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2003-06-27 14:33 Message: Logged In: YES user_id=591932 pushed to 2.4 I'll put up patches that incorporate rhettinger's feedback soon, and definitely in time for the 2.4 branch. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2003-06-27 14:27 Message: Logged In: YES user_id=591932 added Lib/test/test_itertools.py patch here, deleted old item that just had that patch in it ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 16:11 Message: Logged In: YES user_id=80475 *Please post the tests to this patch and close the other patch. *Add a documentation patch to this patch *Let's drop the addition of window(). The C code for it is less than beautiful and offers only a minimal performance gain over the pure python equivalent. I've added the pure python version to the docs so folks can cut and paste it if they need it. Sorry for the wild goose chase (I had expected the C version to be much cleaner and faster and that the python verions would've been harder -- actual code was needed for me to see it). * In roundrobin_next(), replace the % operator with: if (lz->iternum==lz->itersize) lz-iternum=0; * In roundrobin_next(), remove the extra blank line following "long listsize;" * Fixup the indentation, currently it is a mix of spaces and tabs. It should be just pure tabs. * Replace the variable name 'lz' with 'rr'. I should have changed that in other places too but for new code it should be fixed. * 'unti' is mispelled in the docstring. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756253&group_id=5470 From noreply at sourceforge.net Thu Sep 4 05:02:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 4 17:12:48 2003 Subject: [Patches] [ python-Patches-800367 ] Cygwin static core build patch Message-ID: Patches item #800367, was opened at 2003-09-04 03:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=800367&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: Cygwin static core build patch Initial Comment: The attached patch enables the building of Cygwin Python with a static core which still supports shared extensions. It takes advantage the latest Cygwin binutils (i.e., 20030901-1) which can export symbols from executables: http://cygwin.com/ml/cygwin-announce/2003- 09/msg00002.html Additionally, it finally lays to rest the following mailing list subthread: http://mail.python.org/pipermail/python-list/2002- May/102500.html I tested the patch under Red Hat Linux 8.0 too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=800367&group_id=5470 From noreply at sourceforge.net Thu Sep 4 14:54:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 4 17:12:50 2003 Subject: [Patches] [ python-Patches-800697 ] Add 'clear_history()' to 'readline' module Message-ID: Patches item #800697, was opened at 2003-09-04 20:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=800697&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Phillip J. Eby (pje) Assigned to: Nobody/Anonymous (nobody) Summary: Add 'clear_history()' to 'readline' module Initial Comment: This patch adds a 'clear_history()' function to the readline module if the linked-to GNU readline library supports it. (See recent discussion on Python-Dev.) The attached patches are: rl23.txt - patch to readline.c based on current Python CVS HEAD rl223.txt - patch to readline.c based on Python 2.2.3 source distribution rldoc.txt - patch to add docs to Doc/lib/libreadline.tex ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=800697&group_id=5470 From noreply at sourceforge.net Thu Sep 4 13:04:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 4 17:13:16 2003 Subject: [Patches] [ python-Patches-788249 ] explicitly provide a buffer in PyFile_SetBufSize() Message-ID: Patches item #788249, was opened at 2003-08-13 20:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788249&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Andrew Gaul (gaul) Assigned to: Martin v. L?wis (loewis) Summary: explicitly provide a buffer in PyFile_SetBufSize() Initial Comment: Fixes bug 603724. Explicitly provide a buffer for setvbuf() and setbuf() in PyFile_SetBufSize(). The C99 standard allows (and glibc 2.2.5 implements) setvbuf() to ignore the size argument when the buffer argument is NULL. Tested against Python 2.3 on Red Hat 7.3 with glibc 2.2.5-43. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-04 21:04 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as fileobject.h 2.33 fileobject.c 2.181 fileobject.h 2.32.8.1 NEWS 1.831.4.33 fileobject.c 2.179.8.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788249&group_id=5470 From noreply at sourceforge.net Thu Sep 4 12:53:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 4 17:13:29 2003 Subject: [Patches] [ python-Patches-798202 ] detect redhat9 Tcl/Tk in configure script Message-ID: Patches item #798202, was opened at 2003-08-31 19:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798202&group_id=5470 Category: Build Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Martin v. L?wis (loewis) Summary: detect redhat9 Tcl/Tk in configure script Initial Comment: Users have to remember --enable-unicode=ucs4 when compiling on redhat9 to get a working _tkinter.so. This patch autodetects the situation, so that with --enable-unicode=yes ucs4 will be chosen automatically if needed. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-04 20:53 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as configure 1.420 configure.in 1.431 configure 1.416.4.2 configure.in 1.427.4.2 NEWS 1.831.4.32 ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2003-08-31 20:36 Message: Logged In: YES user_id=2772 See also http://mail.python.org/pipermail/python-dev/2003-June/036463.html where I originally posted this patch. I got no negative feedback at the time, but no positive feedback either. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798202&group_id=5470 From noreply at sourceforge.net Thu Sep 4 12:48:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 4 17:13:50 2003 Subject: [Patches] [ python-Patches-794826 ] __file__ attribute missing from dynamicly loaded module Message-ID: Patches item #794826, was opened at 2003-08-25 20:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=794826&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Shack Toms (shacktoms) Assigned to: Martin v. L?wis (loewis) Summary: __file__ attribute missing from dynamicly loaded module Initial Comment: This a patch that corresponds to Bug report [ 698282 ] __file__ attribute missing from dynamicly loaded module, submitted by dsweeton. As he reports, if a single application embeds multiple interpreters, only the one with the first instance of a dynamically loaded module gets the __file__ attribute. It is missing from all later instances. I have attached a cdiff patch, based on his comments. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-04 20:48 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as importdl.c 2.71 and 2.70.14.1, NEWS 1.831.4.31. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=794826&group_id=5470 From noreply at sourceforge.net Thu Sep 4 12:30:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 4 17:14:02 2003 Subject: [Patches] [ python-Patches-792338 ] timetuple() returns a struct_time Message-ID: Patches item #792338, was opened at 2003-08-21 07:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=792338&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Steven Taschuk (staschuk) Assigned to: Martin v. L?wis (loewis) Summary: timetuple() returns a struct_time Initial Comment: The docs for the datetime module describe the return value of the .timetuple() methods as being 9-tuples, when in fact they are instances of time.struct_time. The attached patch is a simple-minded rewrite to make this point clear. (A more sophisticated rewrite might explain why these methods are called "timetuple" even though they don't return tuples.) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-04 20:30 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as libdatetime.tex 1.50 and 1.49.8.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=792338&group_id=5470 From noreply at sourceforge.net Thu Sep 4 12:27:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 4 17:14:16 2003 Subject: [Patches] [ python-Patches-798145 ] nl_langinfo(RADIXCHAR) wrong Message-ID: Patches item #798145, was opened at 2003-08-31 16:12 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798145&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Martin v. L?wis (loewis) Summary: nl_langinfo(RADIXCHAR) wrong Initial Comment: See http://google.com/groups?as_umsgid=m3d6empnsq.fsf%40mira.informatik.hu-berlin.de The following code prints RADIXCHAR from the C locale, not from the chosen locale (fr_FR and many other european locales should give ',' from locale import setlocale, LC_NUMERIC, nl_langinfo, RADIXCHAR setlocale(LC_NUMERIC, "fr_FR") print nl_langinfo(RADIXCHAR) The patch assumes that the value nl_langinfo() should give for RADIXCHAR and THOUSEP are the same as localeconv()['decimal_point'] and ['thousands_sep']. It assumes that if RADIXCHAR is defined then THOUSEP is (just as above code does), How can I write a test for this? Presumably many platforms (Windows?) won't provide a complete set of locales. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-04 20:27 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as test__locale.py 1.1 _localemodule.c 2.42 NEWS 1.831.4.30 _localemodule.c 2.40.4.2 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-31 17:13 Message: Logged In: YES user_id=21627 On non-Posix systems (like Windows), nl_langinfo is not available in the first place, so no need to worry about that. I think the patch is fine. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2003-08-31 16:15 Message: Logged In: YES user_id=2772 Here's one approach to testing: I created a list of all the locales that my system supports which have a differing RADIXCHAR. The test is intended to try all of them, skip if none are found, and fail if any are found but nl_langinfo() disagrees with localeconv() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798145&group_id=5470 From noreply at sourceforge.net Thu Sep 4 08:47:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 4 17:15:01 2003 Subject: [Patches] [ python-Patches-799367 ] effect/affect error in libdatetime.tex Message-ID: Patches item #799367, was opened at 2003-09-02 15:14 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=799367&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven Taschuk (staschuk) >Assigned to: Raymond Hettinger (rhettinger) Summary: effect/affect error in libdatetime.tex Initial Comment: See the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=799367&group_id=5470 From noreply at sourceforge.net Thu Sep 4 08:47:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 4 17:15:10 2003 Subject: [Patches] [ python-Patches-799191 ] Fix ord() documentation Message-ID: Patches item #799191, was opened at 2003-09-02 10:15 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=799191&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) >Assigned to: Raymond Hettinger (rhettinger) Summary: Fix ord() documentation Initial Comment: The online version of the documentation for ord() (currently http://python.org/doc/current/lib/built-in-funcs.html#l2h-55) has a line-break where a backslash should be ('\u2020'). This patch changes \ to \e, which follows practice elsewhere in that file (when representing '\n', for instance) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=799191&group_id=5470 From noreply at sourceforge.net Wed Sep 3 14:07:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 4 19:57:43 2003 Subject: [Patches] [ python-Patches-732401 ] Allows os.forkpty to work on more platforms (Solaris!) Message-ID: Patches item #732401, was opened at 2003-05-04 23:20 Message generated for change (Comment added) made by noah You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732401&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Noah Spurrier (noah) Assigned to: Nobody/Anonymous (nobody) Summary: Allows os.forkpty to work on more platforms (Solaris!) Initial Comment: Recent changes to os.openpty() make it much more portable than earlier versions. Unfortunately, os.forkpty() was not also upgraded. This patch to posixpath.c allows os.forkpty() to run on any platform that supports os.openpty(). This new os.forkpty() will use the C system call forkpty() if available. If not available, then it will do it the old fashioned way with openpty and fork (and only if those too are available, otherwise forkpty remains undefined as before). Other benefits: Since the pty module is based on os.forkpty() this patch will automatically allow pty.fork() to work properly on more platforms. The pty module does not need to be changed. The logic for supporting pty's on multiple platforms can be maintained in one spot instead of in both the posix_module.c and pty.py One of the more notable platforms that does not support the forkpty system call is Solaris. Most importantly to me, this patch will allow os.forkpty() to be available under Solaris. I am testing it with my Pexpect module which makes heavy use of the pty module. With this patch Pexpect passes all my unit tests on Solaris. Pexpect has been tested on Linux, OpenBSD, Solaris, and Cygwin. I'm looking for an OS X server to test with. The code for forkpty should be quite portable and is based on the pty code in OpenSSH and the example in Stevens' "Advanced Programming in the UNIX Environment". I have included a test script, test_forkpty.py. Yours, Noah 

# Test to see if forkpty works. (But don't worry if it

isn't available.)



import os, time

from test.test_support import verbose, TestFailed,

TestSkipped



try:

    if verbose:

        print 'Calling os.forkpty()'

    pid, fd = os.forkpty()

except AttributeError:

    raise TestSkipped, 'No os.forkpty() available.'



if pid == 0: # child

    print 'I am not a robot!'

else:

    if verbose:

        print '(pid, fd) = (%d, %d)' % (pid, fd)

    time.sleep(1) # Give the child a chance to print.

    print 'Robots always say:', os.read(fd,100)

    os.close(fd)
---------------------------------------------------------------------- >Comment By: Noah Spurrier (noah) Date: 2003-09-03 20:07 Message: Logged In: YES user_id=59261 Is there a place where a prospective developer can test on these 8 platforms? I read the Developer FAQ and have been going through the School of Hard Knocks: http://mail.python.org/pipermail/python-dev/2002- September/028725.html I would like to work with someone on this as I only have access to the platforms on Compile Farm from SourceForge. The fact that ptmx support causes HP-UX to hang is probably a simple configuration problem (perhaps incorrectly defining HAVE_DEV_PTMX), but it's impossible for me to research this using only the Compile Farm. Yours, Noah ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-13 20:27 Message: Logged In: YES user_id=21627 The addition of support for ptmx inside posix.openpty has caused the test suite to hang on HP-UX and other systems. A good strategy would be to find some code base, and rigorously test these on all 8 or so supported Unix variants. I'm willing to accept any code that has been tested so, but only after Python 2.3. ---------------------------------------------------------------------- Comment By: Noah Spurrier (noah) Date: 2003-07-13 19:52 Message: Logged In: YES user_id=59261 Which openpty has made pty handling unusable? There are two: os.openpty() and pty.openpty(). What is a good strategy for making pty handling more consistent? I think it's impossible to make pty handling totally platform independent, but Python's pty module could certainly be cleaned up to hide the ugliness. Platforms that are not explicitly handled should probably not define forkpty. Currently Solaris uses the wrong code -- thus leaving the user with the impression that Solaris is supported, but providing a broken implementation. Pty handling is a headache -- I never understood why it was overlooked by POSIX given that ptys are critical to every UNIX system. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-13 15:08 Message: Logged In: YES user_id=21627 It should be deferred. Mere addition of openpty has nearly made the entire pty handling nearly unusable on some systems, as the C library versions of these functions tend to be buggy beyond repair. So I'd rather don't add any more breakage here. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-13 14:06 Message: Logged In: YES user_id=250749 Martin, I've eyeballed the patch and can't see that it would have any effect other than to extend the availability of os.forkpty (assuming that it compiles on all the platforms that it extends to). FreeBSD has forkpty(), so I can't test this myself (I haven't tried to set up a SF compile farm account yet). I'm a little wary about it being this close to 2.3 release - is this worth pursuing at this point, or should it be deferred to post-2.3? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732401&group_id=5470 From noreply at sourceforge.net Thu Sep 4 05:06:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 4 20:30:12 2003 Subject: [Patches] [ python-Patches-800367 ] Cygwin static core build patch Message-ID: Patches item #800367, was opened at 2003-09-04 03:02 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=800367&group_id=5470 Category: Build Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: Cygwin static core build patch Initial Comment: The attached patch enables the building of Cygwin Python with a static core which still supports shared extensions. It takes advantage the latest Cygwin binutils (i.e., 20030901-1) which can export symbols from executables: http://cygwin.com/ml/cygwin-announce/2003- 09/msg00002.html Additionally, it finally lays to rest the following mailing list subthread: http://mail.python.org/pipermail/python-list/2002- May/102500.html I tested the patch under Red Hat Linux 8.0 too. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-09-04 03:06 Message: Logged In: YES user_id=86216 Committed as: Makefile.pre.in 1.137 configure.in 1.430 configure 1.419 Include/pyport.h 2.62 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=800367&group_id=5470 From noreply at sourceforge.net Wed Sep 3 23:28:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 4 21:30:33 2003 Subject: [Patches] [ python-Patches-800236 ] add HTTPResponse.getheaders() Message-ID: Patches item #800236, was opened at 2003-09-04 14:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=800236&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Belmonte (jbelmonte) Assigned to: Nobody/Anonymous (nobody) Summary: add HTTPResponse.getheaders() Initial Comment: Here is a patch to Python 2.3b2+ to add a getheaders method to class HTTPResponse in module httplib. Currently there is no way (using the public interface) to discover response headers. This is useful for debugging, etc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=800236&group_id=5470 From noreply at sourceforge.net Fri Sep 5 23:37:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 6 01:37:27 2003 Subject: [Patches] [ python-Patches-799367 ] effect/affect error in libdatetime.tex Message-ID: Patches item #799367, was opened at 2003-09-02 15:14 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=799367&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Steven Taschuk (staschuk) Assigned to: Raymond Hettinger (rhettinger) Summary: effect/affect error in libdatetime.tex Initial Comment: See the patch. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-06 00:37 Message: Logged In: YES user_id=80475 Accepted and applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=799367&group_id=5470 From noreply at sourceforge.net Fri Sep 5 23:48:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 6 01:48:40 2003 Subject: [Patches] [ python-Patches-799191 ] Fix ord() documentation Message-ID: Patches item #799191, was opened at 2003-09-02 10:15 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=799191&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Raymond Hettinger (rhettinger) Summary: Fix ord() documentation Initial Comment: The online version of the documentation for ord() (currently http://python.org/doc/current/lib/built-in-funcs.html#l2h-55) has a line-break where a backslash should be ('\u2020'). This patch changes \ to \e, which follows practice elsewhere in that file (when representing '\n', for instance) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-06 00:48 Message: Logged In: YES user_id=80475 Accepted and applied. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=799191&group_id=5470 From noreply at sourceforge.net Sat Sep 6 17:31:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 6 19:31:37 2003 Subject: [Patches] [ python-Patches-801821 ] zipimport 64-bit fix Message-ID: Patches item #801821, was opened at 2003-09-07 01:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=801821&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gwenole Beauchesne (gbeauche) Assigned to: Nobody/Anonymous (nobody) Summary: zipimport 64-bit fix Initial Comment: Hi, the following patch fixes regression testing of python2.3 on AMD64 for zipimport test. Classical problem with int vs. long mismatch in varargs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=801821&group_id=5470 From noreply at sourceforge.net Sat Sep 6 18:52:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 6 20:53:02 2003 Subject: [Patches] [ python-Patches-801847 ] Adding rsplit() to string and unicode objects. Message-ID: Patches item #801847, was opened at 2003-09-07 00:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=801847&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Adding rsplit() to string and unicode objects. Initial Comment: I'm attaching patches to the library and documentation for implementing rsplit() on string and unicode objects. This works like split(), but working from the right. ./python -c 'print u"foo, bar, baz".rsplit(None, 1)' [u'foo, bar,', u'baz'] This was supposed to be against the CVS code, but I've had a heck of a time getting it checked out -- my checkout has been hung for half an hour now. The code patch is against the 2.3 release, the docs patch is against the CVS. My checkout got to docs, but I didn't have the code to a point where I could build and test it. Sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=801847&group_id=5470 From noreply at sourceforge.net Sun Sep 7 07:37:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 7 09:37:25 2003 Subject: [Patches] [ python-Patches-801821 ] zipimport 64-bit fix Message-ID: Patches item #801821, was opened at 2003-09-07 01:31 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=801821&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gwenole Beauchesne (gbeauche) >Assigned to: Just van Rossum (jvr) Summary: zipimport 64-bit fix Initial Comment: Hi, the following patch fixes regression testing of python2.3 on AMD64 for zipimport test. Classical problem with int vs. long mismatch in varargs. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-09-07 15:37 Message: Logged In: YES user_id=92689 Thanks, I've checked this in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=801821&group_id=5470 From noreply at sourceforge.net Sun Sep 7 13:49:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 7 15:49:52 2003 Subject: [Patches] [ python-Patches-801847 ] Adding rsplit() to string and unicode objects. Message-ID: Patches item #801847, was opened at 2003-09-07 02:52 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=801847&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Adding rsplit() to string and unicode objects. Initial Comment: I'm attaching patches to the library and documentation for implementing rsplit() on string and unicode objects. This works like split(), but working from the right. ./python -c 'print u"foo, bar, baz".rsplit(None, 1)' [u'foo, bar,', u'baz'] This was supposed to be against the CVS code, but I've had a heck of a time getting it checked out -- my checkout has been hung for half an hour now. The code patch is against the 2.3 release, the docs patch is against the CVS. My checkout got to docs, but I didn't have the code to a point where I could build and test it. Sean ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-07 21:49 Message: Logged In: YES user_id=21627 Why is this function useful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=801847&group_id=5470 From noreply at sourceforge.net Sun Sep 7 18:03:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 7 20:03:58 2003 Subject: [Patches] [ python-Patches-802188 ] better parser error message for non-EOL following line cont. Message-ID: Patches item #802188, was opened at 2003-09-07 18:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=802188&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mathieu Fenniak (laotzu0) Assigned to: Nobody/Anonymous (nobody) Summary: better parser error message for non-EOL following line cont. Initial Comment: This small patch adds a specific error message for when a line continuation character (\) is followed by something other than a newline. If the character following the \ is whitespace, it can be difficult to see why it is an 'invalid token' as the error message used to say. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=802188&group_id=5470 From noreply at sourceforge.net Sun Sep 7 18:56:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 7 20:56:15 2003 Subject: [Patches] [ python-Patches-801847 ] Adding rsplit() to string and unicode objects. Message-ID: Patches item #801847, was opened at 2003-09-07 00:52 Message generated for change (Comment added) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=801847&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Adding rsplit() to string and unicode objects. Initial Comment: I'm attaching patches to the library and documentation for implementing rsplit() on string and unicode objects. This works like split(), but working from the right. ./python -c 'print u"foo, bar, baz".rsplit(None, 1)' [u'foo, bar,', u'baz'] This was supposed to be against the CVS code, but I've had a heck of a time getting it checked out -- my checkout has been hung for half an hour now. The code patch is against the 2.3 release, the docs patch is against the CVS. My checkout got to docs, but I didn't have the code to a point where I could build and test it. Sean ---------------------------------------------------------------------- >Comment By: Sean Reifschneider (jafo) Date: 2003-09-08 00:56 Message: Logged In: YES user_id=81797 Can you provide more details about why the usefulness of this function is in question? First I would like to tell you the story of it coming to be, then I will answer your incomplete question with a (probably) incomplete answer. I had a device which sent me comma-separated fields, but one of the fields in the middle could contain a comma. The answer that seemed obvious to me was to use split with a maxsplit to get the fields up to that field, and then a rsplit with a maxsplit on the remainder. When I mentioned on #python that I was implementing rsplit, 4 other fellow python users replied right away that they had been wanting it. To answer your question, it's useful because people using strings are used to having r*() functions like rfind and rstrip. The lack of rsplit is kind of glaring in this context. Really, though, it's useful because otherwise people have to implement -- often badly. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-07 19:49 Message: Logged In: YES user_id=21627 Why is this function useful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=801847&group_id=5470 From noreply at sourceforge.net Mon Sep 8 14:00:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 8 16:01:05 2003 Subject: [Patches] [ python-Patches-796908 ] decode message attachments in email.Message Message-ID: Patches item #796908, was opened at 2003-08-28 15:46 Message generated for change (Comment added) made by customdesigned You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=796908&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) Assigned to: Nobody/Anonymous (nobody) Summary: decode message attachments in email.Message Initial Comment: This is a fix for bug 794458. It is not a complete fix because although it correctly decodes message attachments on input, the Generator doesn't obey the encoding. I'll fix Generator.py next. ---------------------------------------------------------------------- >Comment By: Stuart D. Gathman (customdesigned) Date: 2003-09-08 16:00 Message: Logged In: YES user_id=142072 I must have forgotten to check the checkbox . . . It may not be necessary to modify Generator. Any valid rfc822 message would not need encoding as a message attachment. If it is desired to preserve the encoding, that is a simple patch to Generator.py, and the Encoding would not be deleted as is done in this patch. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2003-08-31 22:47 Message: Logged In: YES user_id=2772 It looks like you failed to include the attachment/patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=796908&group_id=5470 From noreply at sourceforge.net Tue Sep 9 15:37:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 9 17:37:26 2003 Subject: [Patches] [ python-Patches-803449 ] modernize demo scripts Message-ID: Patches item #803449, was opened at 2003-09-10 06:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=803449&group_id=5470 Category: Demos and tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: modernize demo scripts Initial Comment: I've tried modernizing and cleaning up Vec.py and Rev.py at /Demo/classes/ directory. Changes are: * remove deprecated apply. * use isinstance() instead of type(). * avoid calling list's append method repeatedly. * use string method instead of string module * remove whitespaces inside parentheses. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=803449&group_id=5470 From noreply at sourceforge.net Wed Sep 10 00:12:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 10 02:12:17 2003 Subject: [Patches] [ python-Patches-796772 ] CGIHTTPServer fix Message-ID: Patches item #796772, was opened at 2003-08-28 18:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=796772&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer fix Initial Comment: Here's a fix for the CGI server. The problem only occurs on systems that support os.fork(). When you invoke a CGI script with a query string and then subsequent invoke it without a query string (or with an empty query string), the second invocation gets passed the query string of the first invocation. This is because of the way os.environ is updated in the parent, but when there is no query string, the old query string doesn't get deleted. The solution is to update the os.environ in the child. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-10 08:12 Message: Logged In: YES user_id=21627 I agree with rhettinger. The original patch assumes that the platform has putenv/setenv, which it might not (if it doesn't, then the os.environ.update is not reflected in the C environment, and thus has no effect on os.execv). Whether or not os.environ needs to be copied is debatable; the copying has its cost, but avoiding the putenv calls would save some of the costs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-31 16:48 Message: Logged In: YES user_id=80475 The first part of the patch makes sense to me. The second part updates os.environ which is shared between successive calls. I would have expected something like: childenv = os.environ.copy() childenv.update(env) . . . os.execve(scriptfile, args, childenv) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=796772&group_id=5470 From noreply at sourceforge.net Wed Sep 10 10:20:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 10 12:20:16 2003 Subject: [Patches] [ python-Patches-787789 ] unittest.py: Custom TestRunners and --verbose Message-ID: Patches item #787789, was opened at 2003-08-13 05:31 Message generated for change (Comment added) made by purcell You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=787789&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None >Priority: 3 Submitted By: Matthew F. Barnes (mfbarnes) Assigned to: Steve Purcell (purcell) Summary: unittest.py: Custom TestRunners and --verbose Initial Comment: The unittest.TestProgram class accepts a "--verbose" command-line argument. But the setting only gets applied if the testRunner argument to unittest.TestProgram.__init__ is None. There is no clean way of creating a custom TestRunner class and passing it to unittest.TestProgram such that the correct verbosity is picked up. This patch slightly alters the interface to unittest.TestProgram.__init__ by allowing a class to be passed as the testRunner argument (defaulting to TextTestRunner instead of None). Then the runTests method of unittest.TestProgram checks whether self.testRunner is a class, and if so creates an instance of it, passing the correct verbosity setting to the TestRunner class' __init__ method. The patch should still allow a custom TestRunner class _instance_ to be passed to unittest.TestProgram.__init__. ---------------------------------------------------------------------- >Comment By: Steve Purcell (purcell) Date: 2003-09-10 18:20 Message: Logged In: YES user_id=21477 I can see your point, but this requres every test runner to accept the 'verbosity' keyword argument. I'm worried that this will break a large number of custom test runners. Another approach might be to change TextTestRunner so that 'verbosity' is an instance attribute that is set by TestProgram after the test runner instance is created. Then existing custom test runners will not break, unless they already have a 'verbosity' attribute, which is unlikely. I'll bear this patch in mind; I'm looking at a few pending minor changes to the module, and this area is one that I'm covering. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=787789&group_id=5470 From noreply at sourceforge.net Wed Sep 10 11:08:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 10 13:08:32 2003 Subject: [Patches] [ python-Patches-801847 ] Adding rsplit() to string and unicode objects. Message-ID: Patches item #801847, was opened at 2003-09-07 02:52 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=801847&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Adding rsplit() to string and unicode objects. Initial Comment: I'm attaching patches to the library and documentation for implementing rsplit() on string and unicode objects. This works like split(), but working from the right. ./python -c 'print u"foo, bar, baz".rsplit(None, 1)' [u'foo, bar,', u'baz'] This was supposed to be against the CVS code, but I've had a heck of a time getting it checked out -- my checkout has been hung for half an hour now. The code patch is against the 2.3 release, the docs patch is against the CVS. My checkout got to docs, but I didn't have the code to a point where I could build and test it. Sean ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-10 19:08 Message: Logged In: YES user_id=21627 I questioned the usefulness because I could not think of a meaningful application. Now I see what a potential application could be, but I doubt its generality, because that approach would break if there could be two fields that have commas in them. I also disagree that symmetry can motivate usefulness: I also doubt that all of the r* functions are useful, but they cannot be removed for backwards compatibility. The fact that rsplit would fit together with the other r* functions indicates that adding rsplit would provide symmetry, not that it would provide usefulness. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-08 02:56 Message: Logged In: YES user_id=81797 Can you provide more details about why the usefulness of this function is in question? First I would like to tell you the story of it coming to be, then I will answer your incomplete question with a (probably) incomplete answer. I had a device which sent me comma-separated fields, but one of the fields in the middle could contain a comma. The answer that seemed obvious to me was to use split with a maxsplit to get the fields up to that field, and then a rsplit with a maxsplit on the remainder. When I mentioned on #python that I was implementing rsplit, 4 other fellow python users replied right away that they had been wanting it. To answer your question, it's useful because people using strings are used to having r*() functions like rfind and rstrip. The lack of rsplit is kind of glaring in this context. Really, though, it's useful because otherwise people have to implement -- often badly. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-07 21:49 Message: Logged In: YES user_id=21627 Why is this function useful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=801847&group_id=5470 From noreply at sourceforge.net Wed Sep 10 13:03:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 10 15:03:40 2003 Subject: [Patches] [ python-Patches-803449 ] modernize demo scripts Message-ID: Patches item #803449, was opened at 2003-09-09 16:37 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=803449&group_id=5470 Category: Demos and tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) >Assigned to: Raymond Hettinger (rhettinger) Summary: modernize demo scripts Initial Comment: I've tried modernizing and cleaning up Vec.py and Rev.py at /Demo/classes/ directory. Changes are: * remove deprecated apply. * use isinstance() instead of type(). * avoid calling list's append method repeatedly. * use string method instead of string module * remove whitespaces inside parentheses. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=803449&group_id=5470 From noreply at sourceforge.net Wed Sep 10 13:15:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 10 15:15:13 2003 Subject: [Patches] [ python-Patches-801847 ] Adding rsplit() to string and unicode objects. Message-ID: Patches item #801847, was opened at 2003-09-07 00:52 Message generated for change (Comment added) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=801847&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Adding rsplit() to string and unicode objects. Initial Comment: I'm attaching patches to the library and documentation for implementing rsplit() on string and unicode objects. This works like split(), but working from the right. ./python -c 'print u"foo, bar, baz".rsplit(None, 1)' [u'foo, bar,', u'baz'] This was supposed to be against the CVS code, but I've had a heck of a time getting it checked out -- my checkout has been hung for half an hour now. The code patch is against the 2.3 release, the docs patch is against the CVS. My checkout got to docs, but I didn't have the code to a point where I could build and test it. Sean ---------------------------------------------------------------------- >Comment By: Sean Reifschneider (jafo) Date: 2003-09-10 19:15 Message: Logged In: YES user_id=81797 os.path.basename/os.path.dirname is an example of where you could use rsplit. One of the other #python folks said he had recently wanted rsplit for an application where he was getting the domain name and user part from a list of e-mail addresses, but found that some entries contained an "@" in the user part. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-10 17:08 Message: Logged In: YES user_id=21627 I questioned the usefulness because I could not think of a meaningful application. Now I see what a potential application could be, but I doubt its generality, because that approach would break if there could be two fields that have commas in them. I also disagree that symmetry can motivate usefulness: I also doubt that all of the r* functions are useful, but they cannot be removed for backwards compatibility. The fact that rsplit would fit together with the other r* functions indicates that adding rsplit would provide symmetry, not that it would provide usefulness. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-08 00:56 Message: Logged In: YES user_id=81797 Can you provide more details about why the usefulness of this function is in question? First I would like to tell you the story of it coming to be, then I will answer your incomplete question with a (probably) incomplete answer. I had a device which sent me comma-separated fields, but one of the fields in the middle could contain a comma. The answer that seemed obvious to me was to use split with a maxsplit to get the fields up to that field, and then a rsplit with a maxsplit on the remainder. When I mentioned on #python that I was implementing rsplit, 4 other fellow python users replied right away that they had been wanting it. To answer your question, it's useful because people using strings are used to having r*() functions like rfind and rstrip. The lack of rsplit is kind of glaring in this context. Really, though, it's useful because otherwise people have to implement -- often badly. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-07 19:49 Message: Logged In: YES user_id=21627 Why is this function useful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=801847&group_id=5470 From noreply at sourceforge.net Wed Sep 10 13:35:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 10 15:35:12 2003 Subject: [Patches] [ python-Patches-801847 ] Adding rsplit() to string and unicode objects. Message-ID: Patches item #801847, was opened at 2003-09-06 19:52 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=801847&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Adding rsplit() to string and unicode objects. Initial Comment: I'm attaching patches to the library and documentation for implementing rsplit() on string and unicode objects. This works like split(), but working from the right. ./python -c 'print u"foo, bar, baz".rsplit(None, 1)' [u'foo, bar,', u'baz'] This was supposed to be against the CVS code, but I've had a heck of a time getting it checked out -- my checkout has been hung for half an hour now. The code patch is against the 2.3 release, the docs patch is against the CVS. My checkout got to docs, but I didn't have the code to a point where I could build and test it. Sean ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-10 14:35 Message: Logged In: YES user_id=80475 I would classify this more as a technique than a fundamental string operation implemented by all stringlike objects (including UserString). Accordingly, I recommend that the patch be closed and a recipe posted in the ASPN cookbook - something along the lines of: >>> def rsplit(s, sep=None, maxsplit=-1): ... return [chunk[::-1] for chunk in s[::-1].split(sep, maxsplit)[::-1]] >>> rsplit(u"foo, bar, baz", None, 1) [u'foo, bar,', u'baz'] ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-10 14:15 Message: Logged In: YES user_id=81797 os.path.basename/os.path.dirname is an example of where you could use rsplit. One of the other #python folks said he had recently wanted rsplit for an application where he was getting the domain name and user part from a list of e-mail addresses, but found that some entries contained an "@" in the user part. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-10 12:08 Message: Logged In: YES user_id=21627 I questioned the usefulness because I could not think of a meaningful application. Now I see what a potential application could be, but I doubt its generality, because that approach would break if there could be two fields that have commas in them. I also disagree that symmetry can motivate usefulness: I also doubt that all of the r* functions are useful, but they cannot be removed for backwards compatibility. The fact that rsplit would fit together with the other r* functions indicates that adding rsplit would provide symmetry, not that it would provide usefulness. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-07 19:56 Message: Logged In: YES user_id=81797 Can you provide more details about why the usefulness of this function is in question? First I would like to tell you the story of it coming to be, then I will answer your incomplete question with a (probably) incomplete answer. I had a device which sent me comma-separated fields, but one of the fields in the middle could contain a comma. The answer that seemed obvious to me was to use split with a maxsplit to get the fields up to that field, and then a rsplit with a maxsplit on the remainder. When I mentioned on #python that I was implementing rsplit, 4 other fellow python users replied right away that they had been wanting it. To answer your question, it's useful because people using strings are used to having r*() functions like rfind and rstrip. The lack of rsplit is kind of glaring in this context. Really, though, it's useful because otherwise people have to implement -- often badly. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-07 14:49 Message: Logged In: YES user_id=21627 Why is this function useful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=801847&group_id=5470 From noreply at sourceforge.net Wed Sep 10 14:40:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 10 16:40:51 2003 Subject: [Patches] [ python-Patches-801847 ] Adding rsplit() to string and unicode objects. Message-ID: Patches item #801847, was opened at 2003-09-07 00:52 Message generated for change (Comment added) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=801847&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Adding rsplit() to string and unicode objects. Initial Comment: I'm attaching patches to the library and documentation for implementing rsplit() on string and unicode objects. This works like split(), but working from the right. ./python -c 'print u"foo, bar, baz".rsplit(None, 1)' [u'foo, bar,', u'baz'] This was supposed to be against the CVS code, but I've had a heck of a time getting it checked out -- my checkout has been hung for half an hour now. The code patch is against the 2.3 release, the docs patch is against the CVS. My checkout got to docs, but I didn't have the code to a point where I could build and test it. Sean ---------------------------------------------------------------------- >Comment By: Sean Reifschneider (jafo) Date: 2003-09-10 20:40 Message: Logged In: YES user_id=81797 I realize that rsplit() can be implemented, because, well, I implemented it. The standard library is there to provide ready-to-use functionality so that users of python can concentrate on their program instead of concentrate on re-inventing the wheel. find() can be implemented with a short loop, split() can be implemented with find(), join() can be implemented with a short loop. Many things can be implemented with a little additional effort on the part of the user to develop or locate the code they're wanting. These little things can add up quickly and can have quite a dramatic impact on the programming experience in Python. Having to find or implement these functions will cause distraction from the code at hand, time lost while finding, implementing, testing, and maintaining the code in question. One of Python's strengths is a rich standard library. So, what are the guidelines for determining when it's rich enough? Why is it ok to suggest that users should get distracted from their code to go implement something else? Is there a policy that I'm not aware of that new functionality should be put in the cookbook instead of the standard library? Why is it being ignored that some programmers would find implementing rsplit() challenging? I'm not trying to be difficult here, I honestly can't understand the apparent change from having a rich library to a "batteries not included" stance. The response I got from #python when I mentioned having submitted the patch indicates to me that other experienced Python developers expect there to be an rsplit(). So, why is there so much resistance to adding something to the library? What are the guidelines for determining if something should be in the library? Sean ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-10 19:35 Message: Logged In: YES user_id=80475 I would classify this more as a technique than a fundamental string operation implemented by all stringlike objects (including UserString). Accordingly, I recommend that the patch be closed and a recipe posted in the ASPN cookbook - something along the lines of: >>> def rsplit(s, sep=None, maxsplit=-1): ... return [chunk[::-1] for chunk in s[::-1].split(sep, maxsplit)[::-1]] >>> rsplit(u"foo, bar, baz", None, 1) [u'foo, bar,', u'baz'] ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-10 19:15 Message: Logged In: YES user_id=81797 os.path.basename/os.path.dirname is an example of where you could use rsplit. One of the other #python folks said he had recently wanted rsplit for an application where he was getting the domain name and user part from a list of e-mail addresses, but found that some entries contained an "@" in the user part. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-10 17:08 Message: Logged In: YES user_id=21627 I questioned the usefulness because I could not think of a meaningful application. Now I see what a potential application could be, but I doubt its generality, because that approach would break if there could be two fields that have commas in them. I also disagree that symmetry can motivate usefulness: I also doubt that all of the r* functions are useful, but they cannot be removed for backwards compatibility. The fact that rsplit would fit together with the other r* functions indicates that adding rsplit would provide symmetry, not that it would provide usefulness. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-08 00:56 Message: Logged In: YES user_id=81797 Can you provide more details about why the usefulness of this function is in question? First I would like to tell you the story of it coming to be, then I will answer your incomplete question with a (probably) incomplete answer. I had a device which sent me comma-separated fields, but one of the fields in the middle could contain a comma. The answer that seemed obvious to me was to use split with a maxsplit to get the fields up to that field, and then a rsplit with a maxsplit on the remainder. When I mentioned on #python that I was implementing rsplit, 4 other fellow python users replied right away that they had been wanting it. To answer your question, it's useful because people using strings are used to having r*() functions like rfind and rstrip. The lack of rsplit is kind of glaring in this context. Really, though, it's useful because otherwise people have to implement -- often badly. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-07 19:49 Message: Logged In: YES user_id=21627 Why is this function useful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=801847&group_id=5470 From noreply at sourceforge.net Wed Sep 10 14:51:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 10 16:51:36 2003 Subject: [Patches] [ python-Patches-803998 ] [_ssl.c] SSL_write() called with -1 as size Message-ID: Patches item #803998, was opened at 2003-09-10 22:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=803998&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ilario Nardinocchi (illo) Assigned to: Nobody/Anonymous (nobody) Summary: [_ssl.c] SSL_write() called with -1 as size Initial Comment: In the inner do/while loop of PySSL_SSLwrite(), whenever a SSL_write() needs to be called again after a SSL_ERROR_WANT_{READ,WRITE} error, its "len" parameter is set to -1, leading to a segfault. I can't believe nobody ever noticed that :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=803998&group_id=5470 From noreply at sourceforge.net Wed Sep 10 15:13:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 10 17:13:36 2003 Subject: [Patches] [ python-Patches-803449 ] modernize demo scripts Message-ID: Patches item #803449, was opened at 2003-09-09 16:37 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=803449&group_id=5470 Category: Demos and tools Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Raymond Hettinger (rhettinger) Summary: modernize demo scripts Initial Comment: I've tried modernizing and cleaning up Vec.py and Rev.py at /Demo/classes/ directory. Changes are: * remove deprecated apply. * use isinstance() instead of type(). * avoid calling list's append method repeatedly. * use string method instead of string module * remove whitespaces inside parentheses. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-10 16:13 Message: Logged In: YES user_id=80475 Accepted and applied after a few mofications. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=803449&group_id=5470 From noreply at sourceforge.net Wed Sep 10 19:11:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 10 21:11:11 2003 Subject: [Patches] [ python-Patches-791706 ] POP3 over SSL support for poplib Message-ID: Patches item #791706, was opened at 2003-08-20 05:53 Message generated for change (Comment added) made by mrbook You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=791706&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hector urtubia (mrbook) Assigned to: Nobody/Anonymous (nobody) Summary: POP3 over SSL support for poplib Initial Comment: This patch creates a class POP3_SSL which is a child of POP3 on the poplib module. This class is able to handle POP3 over SSL. It borrows some code from IMAP_SSL. ---------------------------------------------------------------------- >Comment By: Hector urtubia (mrbook) Date: 2003-09-11 01:11 Message: Logged In: YES user_id=10927 I have added a patch for the documentation (lipoplibdoc- 1_0.patch) and have addressed most of the requests from the reviewer on newer patch revision (poplibssl-1_0.patch). - Tabs and spaces issues fixed - Fixed port on comment - Data is now read on big chunks - Unable to reuse base-claass __init__ because of parent's design issues. Cheers. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-31 16:38 Message: Logged In: YES user_id=21627 Can you please provide a patch for the documentation as well? Please don't mix tabs and spaces; I recommend to run reindent.py before producing the diff. In the class comment, the default port is incorrect. Please don't build up strings by adding one character at a time, use [c]StringIO instead, or a list. Also consider reading larger chunks of data a time, buffering extra data in the class. Try to reuse the base-class __init__. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=791706&group_id=5470 From noreply at sourceforge.net Wed Sep 10 23:07:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 11 01:07:46 2003 Subject: [Patches] [ python-Patches-804180 ] A ForwardingHandler for logging Message-ID: Patches item #804180, was opened at 2003-09-11 00:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804180&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew F. Barnes (mfbarnes) Assigned to: Nobody/Anonymous (nobody) Summary: A ForwardingHandler for logging Initial Comment: This was suggested recently on python-dev. I'm proposing it as an addition to the standard set of handlers in the logging package. ForwardingHandler simply forwards logging records to another logger elsewhere in the logging hierarchy. I like to think of this handler as a "softlink" for logging. The initialization method accepts the name of the logger object it should forward to, which is then fetched using getLogger(). This is preferrable to accepting the logger object itself because it's easier for a configuration file to reference another logger by its "qualname". If a name is not given to the initialization method, the handler will forward to the root logger. The emit method guards against infinite loops that would result from a logger object forwarding to itself (perhaps the result of misconfiguration). The attached file is not a "diff" file but just a code fragment that can be inserted somewhere in logging/__init__.py (or in logging/handlers.py with some minor modifications). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804180&group_id=5470 From noreply at sourceforge.net Thu Sep 11 00:07:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 11 02:07:30 2003 Subject: [Patches] [ python-Patches-801847 ] Adding rsplit() to string and unicode objects. Message-ID: Patches item #801847, was opened at 2003-09-07 02:52 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=801847&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Adding rsplit() to string and unicode objects. Initial Comment: I'm attaching patches to the library and documentation for implementing rsplit() on string and unicode objects. This works like split(), but working from the right. ./python -c 'print u"foo, bar, baz".rsplit(None, 1)' [u'foo, bar,', u'baz'] This was supposed to be against the CVS code, but I've had a heck of a time getting it checked out -- my checkout has been hung for half an hour now. The code patch is against the 2.3 release, the docs patch is against the CVS. My checkout got to docs, but I didn't have the code to a point where I could build and test it. Sean ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-11 08:07 Message: Logged In: YES user_id=21627 There is PEP 2, which suggests to write a library PEP for proposal to extend the library. Now, this probably would be overkill for a single string method. However, I feel that there are already too many string methods, so I won't accept that patch. I'm not rejecting it, either, because I see that other maintainers might have a different opinion. In short, you should propose your change to python-dev, finding out what "a majority" of the maintainers thinks; you might also propose it on python-list, trying to collect reactions from users. It would then be good to summarize these discussions here (instead of carrying them out here). ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-10 22:40 Message: Logged In: YES user_id=81797 I realize that rsplit() can be implemented, because, well, I implemented it. The standard library is there to provide ready-to-use functionality so that users of python can concentrate on their program instead of concentrate on re-inventing the wheel. find() can be implemented with a short loop, split() can be implemented with find(), join() can be implemented with a short loop. Many things can be implemented with a little additional effort on the part of the user to develop or locate the code they're wanting. These little things can add up quickly and can have quite a dramatic impact on the programming experience in Python. Having to find or implement these functions will cause distraction from the code at hand, time lost while finding, implementing, testing, and maintaining the code in question. One of Python's strengths is a rich standard library. So, what are the guidelines for determining when it's rich enough? Why is it ok to suggest that users should get distracted from their code to go implement something else? Is there a policy that I'm not aware of that new functionality should be put in the cookbook instead of the standard library? Why is it being ignored that some programmers would find implementing rsplit() challenging? I'm not trying to be difficult here, I honestly can't understand the apparent change from having a rich library to a "batteries not included" stance. The response I got from #python when I mentioned having submitted the patch indicates to me that other experienced Python developers expect there to be an rsplit(). So, why is there so much resistance to adding something to the library? What are the guidelines for determining if something should be in the library? Sean ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-10 21:35 Message: Logged In: YES user_id=80475 I would classify this more as a technique than a fundamental string operation implemented by all stringlike objects (including UserString). Accordingly, I recommend that the patch be closed and a recipe posted in the ASPN cookbook - something along the lines of: >>> def rsplit(s, sep=None, maxsplit=-1): ... return [chunk[::-1] for chunk in s[::-1].split(sep, maxsplit)[::-1]] >>> rsplit(u"foo, bar, baz", None, 1) [u'foo, bar,', u'baz'] ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-10 21:15 Message: Logged In: YES user_id=81797 os.path.basename/os.path.dirname is an example of where you could use rsplit. One of the other #python folks said he had recently wanted rsplit for an application where he was getting the domain name and user part from a list of e-mail addresses, but found that some entries contained an "@" in the user part. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-10 19:08 Message: Logged In: YES user_id=21627 I questioned the usefulness because I could not think of a meaningful application. Now I see what a potential application could be, but I doubt its generality, because that approach would break if there could be two fields that have commas in them. I also disagree that symmetry can motivate usefulness: I also doubt that all of the r* functions are useful, but they cannot be removed for backwards compatibility. The fact that rsplit would fit together with the other r* functions indicates that adding rsplit would provide symmetry, not that it would provide usefulness. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-08 02:56 Message: Logged In: YES user_id=81797 Can you provide more details about why the usefulness of this function is in question? First I would like to tell you the story of it coming to be, then I will answer your incomplete question with a (probably) incomplete answer. I had a device which sent me comma-separated fields, but one of the fields in the middle could contain a comma. The answer that seemed obvious to me was to use split with a maxsplit to get the fields up to that field, and then a rsplit with a maxsplit on the remainder. When I mentioned on #python that I was implementing rsplit, 4 other fellow python users replied right away that they had been wanting it. To answer your question, it's useful because people using strings are used to having r*() functions like rfind and rstrip. The lack of rsplit is kind of glaring in this context. Really, though, it's useful because otherwise people have to implement -- often badly. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-07 21:49 Message: Logged In: YES user_id=21627 Why is this function useful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=801847&group_id=5470 From noreply at sourceforge.net Thu Sep 11 00:52:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 11 02:52:26 2003 Subject: [Patches] [ python-Patches-804212 ] unittest's main don't handle TestSuite in command line Message-ID: Patches item #804212, was opened at 2003-09-11 09:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804212&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: unittest's main don't handle TestSuite in command line Initial Comment: When using unittest's "main" it fails if in the command line a name of TestSuite class is given. Suppose ts.py is: ---- #!/usr/bin/env python from unittest import TestCase, makeSuite, main class T(TestCase): def test_moo(self): self.fail() test_suite = makeSuite(T, "test_") if __name__ == "__main__": main() ---- Then running "ts.py test_suite" will fail. Attached is a patch for unittest.py Miki ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804212&group_id=5470 From noreply at sourceforge.net Thu Sep 11 04:00:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 11 06:00:58 2003 Subject: [Patches] [ python-Patches-804280 ] fromkeys is not listed in index Message-ID: Patches item #804280, was opened at 2003-09-11 19:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804280&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: fromkeys is not listed in index Initial Comment: I've noticed that fromkeys(dict method) is not listed in the index page of "Python Library Reference". http://www.python.org/dev/doc/devel/lib/genindex.h tml Attached patch should fix this. I've also removed some empty spaces trailing at the end of line. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804280&group_id=5470 From noreply at sourceforge.net Thu Sep 11 17:55:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 11 19:55:40 2003 Subject: [Patches] [ python-Patches-801847 ] Adding rsplit() to string and unicode objects. Message-ID: Patches item #801847, was opened at 2003-09-06 19:52 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=801847&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) >Assigned to: Guido van Rossum (gvanrossum) Summary: Adding rsplit() to string and unicode objects. Initial Comment: I'm attaching patches to the library and documentation for implementing rsplit() on string and unicode objects. This works like split(), but working from the right. ./python -c 'print u"foo, bar, baz".rsplit(None, 1)' [u'foo, bar,', u'baz'] This was supposed to be against the CVS code, but I've had a heck of a time getting it checked out -- my checkout has been hung for half an hour now. The code patch is against the 2.3 release, the docs patch is against the CVS. My checkout got to docs, but I didn't have the code to a point where I could build and test it. Sean ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-11 18:55 Message: Logged In: YES user_id=80475 Guido, do you care to pronounce on this one? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-11 01:07 Message: Logged In: YES user_id=21627 There is PEP 2, which suggests to write a library PEP for proposal to extend the library. Now, this probably would be overkill for a single string method. However, I feel that there are already too many string methods, so I won't accept that patch. I'm not rejecting it, either, because I see that other maintainers might have a different opinion. In short, you should propose your change to python-dev, finding out what "a majority" of the maintainers thinks; you might also propose it on python-list, trying to collect reactions from users. It would then be good to summarize these discussions here (instead of carrying them out here). ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-10 15:40 Message: Logged In: YES user_id=81797 I realize that rsplit() can be implemented, because, well, I implemented it. The standard library is there to provide ready-to-use functionality so that users of python can concentrate on their program instead of concentrate on re-inventing the wheel. find() can be implemented with a short loop, split() can be implemented with find(), join() can be implemented with a short loop. Many things can be implemented with a little additional effort on the part of the user to develop or locate the code they're wanting. These little things can add up quickly and can have quite a dramatic impact on the programming experience in Python. Having to find or implement these functions will cause distraction from the code at hand, time lost while finding, implementing, testing, and maintaining the code in question. One of Python's strengths is a rich standard library. So, what are the guidelines for determining when it's rich enough? Why is it ok to suggest that users should get distracted from their code to go implement something else? Is there a policy that I'm not aware of that new functionality should be put in the cookbook instead of the standard library? Why is it being ignored that some programmers would find implementing rsplit() challenging? I'm not trying to be difficult here, I honestly can't understand the apparent change from having a rich library to a "batteries not included" stance. The response I got from #python when I mentioned having submitted the patch indicates to me that other experienced Python developers expect there to be an rsplit(). So, why is there so much resistance to adding something to the library? What are the guidelines for determining if something should be in the library? Sean ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-10 14:35 Message: Logged In: YES user_id=80475 I would classify this more as a technique than a fundamental string operation implemented by all stringlike objects (including UserString). Accordingly, I recommend that the patch be closed and a recipe posted in the ASPN cookbook - something along the lines of: >>> def rsplit(s, sep=None, maxsplit=-1): ... return [chunk[::-1] for chunk in s[::-1].split(sep, maxsplit)[::-1]] >>> rsplit(u"foo, bar, baz", None, 1) [u'foo, bar,', u'baz'] ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-10 14:15 Message: Logged In: YES user_id=81797 os.path.basename/os.path.dirname is an example of where you could use rsplit. One of the other #python folks said he had recently wanted rsplit for an application where he was getting the domain name and user part from a list of e-mail addresses, but found that some entries contained an "@" in the user part. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-10 12:08 Message: Logged In: YES user_id=21627 I questioned the usefulness because I could not think of a meaningful application. Now I see what a potential application could be, but I doubt its generality, because that approach would break if there could be two fields that have commas in them. I also disagree that symmetry can motivate usefulness: I also doubt that all of the r* functions are useful, but they cannot be removed for backwards compatibility. The fact that rsplit would fit together with the other r* functions indicates that adding rsplit would provide symmetry, not that it would provide usefulness. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-07 19:56 Message: Logged In: YES user_id=81797 Can you provide more details about why the usefulness of this function is in question? First I would like to tell you the story of it coming to be, then I will answer your incomplete question with a (probably) incomplete answer. I had a device which sent me comma-separated fields, but one of the fields in the middle could contain a comma. The answer that seemed obvious to me was to use split with a maxsplit to get the fields up to that field, and then a rsplit with a maxsplit on the remainder. When I mentioned on #python that I was implementing rsplit, 4 other fellow python users replied right away that they had been wanting it. To answer your question, it's useful because people using strings are used to having r*() functions like rfind and rstrip. The lack of rsplit is kind of glaring in this context. Really, though, it's useful because otherwise people have to implement -- often badly. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-07 14:49 Message: Logged In: YES user_id=21627 Why is this function useful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=801847&group_id=5470 From noreply at sourceforge.net Thu Sep 11 18:04:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 11 20:04:28 2003 Subject: [Patches] [ python-Patches-804280 ] fromkeys is not listed in index Message-ID: Patches item #804280, was opened at 2003-09-11 05:00 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804280&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: fromkeys is not listed in index Initial Comment: I've noticed that fromkeys(dict method) is not listed in the index page of "Python Library Reference". http://www.python.org/dev/doc/devel/lib/genindex.h tml Attached patch should fix this. I've also removed some empty spaces trailing at the end of line. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-11 19:04 Message: Logged In: YES user_id=80475 Accepted and applied. Thank you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804280&group_id=5470 From noreply at sourceforge.net Thu Sep 11 18:10:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 11 20:10:07 2003 Subject: [Patches] [ python-Patches-804180 ] A ForwardingHandler for logging Message-ID: Patches item #804180, was opened at 2003-09-11 00:07 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804180&group_id=5470 Category: Library (Lib) >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthew F. Barnes (mfbarnes) >Assigned to: Raymond Hettinger (rhettinger) Summary: A ForwardingHandler for logging Initial Comment: This was suggested recently on python-dev. I'm proposing it as an addition to the standard set of handlers in the logging package. ForwardingHandler simply forwards logging records to another logger elsewhere in the logging hierarchy. I like to think of this handler as a "softlink" for logging. The initialization method accepts the name of the logger object it should forward to, which is then fetched using getLogger(). This is preferrable to accepting the logger object itself because it's easier for a configuration file to reference another logger by its "qualname". If a name is not given to the initialization method, the handler will forward to the root logger. The emit method guards against infinite loops that would result from a logger object forwarding to itself (perhaps the result of misconfiguration). The attached file is not a "diff" file but just a code fragment that can be inserted somewhere in logging/__init__.py (or in logging/handlers.py with some minor modifications). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804180&group_id=5470 From noreply at sourceforge.net Thu Sep 11 18:10:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 11 20:10:52 2003 Subject: [Patches] [ python-Patches-804212 ] unittest's main don't handle TestSuite in command line Message-ID: Patches item #804212, was opened at 2003-09-11 01:52 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804212&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) >Assigned to: Raymond Hettinger (rhettinger) Summary: unittest's main don't handle TestSuite in command line Initial Comment: When using unittest's "main" it fails if in the command line a name of TestSuite class is given. Suppose ts.py is: ---- #!/usr/bin/env python from unittest import TestCase, makeSuite, main class T(TestCase): def test_moo(self): self.fail() test_suite = makeSuite(T, "test_") if __name__ == "__main__": main() ---- Then running "ts.py test_suite" will fail. Attached is a patch for unittest.py Miki ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804212&group_id=5470 From noreply at sourceforge.net Thu Sep 11 19:06:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 11 21:06:48 2003 Subject: [Patches] [ python-Patches-804180 ] A ForwardingHandler for logging Message-ID: Patches item #804180, was opened at 2003-09-11 05:07 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804180&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthew F. Barnes (mfbarnes) Assigned to: Raymond Hettinger (rhettinger) Summary: A ForwardingHandler for logging Initial Comment: This was suggested recently on python-dev. I'm proposing it as an addition to the standard set of handlers in the logging package. ForwardingHandler simply forwards logging records to another logger elsewhere in the logging hierarchy. I like to think of this handler as a "softlink" for logging. The initialization method accepts the name of the logger object it should forward to, which is then fetched using getLogger(). This is preferrable to accepting the logger object itself because it's easier for a configuration file to reference another logger by its "qualname". If a name is not given to the initialization method, the handler will forward to the root logger. The emit method guards against infinite loops that would result from a logger object forwarding to itself (perhaps the result of misconfiguration). The attached file is not a "diff" file but just a code fragment that can be inserted somewhere in logging/__init__.py (or in logging/handlers.py with some minor modifications). ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-09-12 01:06 Message: Logged In: YES user_id=308438 I would make the following comments about this patch: 1. The logger name captures what happened/where it happened. If an event gets forwarded to a different logger, it just gets handled by that logger's handlers (assuming filtering lets it through), but is otherwise unchanged. If you forward an event from "asyncore" to "myapp.network.asyncore", the name would not change - it would get passed to "myapp.network.asyncore" handlers but still get emitted with a name of "asyncore". The same effect could be achieved by configuring handlers appropriately. Doing it this way, you could quite get easily get duplicated messages, which makes logs less useful. Particularly, the defaulting to the root logger is not a good idea - since many events filter up to the root logger, it would be very easy with the default to get lots of duplicated messages. 2. In ForwardingHandler.emit, self is a ForwardingHandler but self.recipient is a Logger. So the "if" condition will always evaluate to true. 3. Event loggers are the equivalent of "publish", and event handlers the equivalent of "subscribe". Mixing the two is not necessarily such a good idea. Events should be logged, by the developer, using a logger name which makes sense in the context of the module, subsystem or application. So, if an event occurs in "asyncore", we want to know that it happened in "asyncore". But if I want to see it interspersed with other stuff I'm doing in "myapp.network.asyncore", an application built on top of asyncore, I just add the same logger to "asyncore" and "myapp.network.asyncore", and I can see both sets of events together. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804180&group_id=5470 From noreply at sourceforge.net Thu Sep 11 23:32:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 12 01:32:53 2003 Subject: [Patches] [ python-Patches-804180 ] A ForwardingHandler for logging Message-ID: Patches item #804180, was opened at 2003-09-11 00:07 Message generated for change (Comment added) made by mfbarnes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804180&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthew F. Barnes (mfbarnes) Assigned to: Raymond Hettinger (rhettinger) Summary: A ForwardingHandler for logging Initial Comment: This was suggested recently on python-dev. I'm proposing it as an addition to the standard set of handlers in the logging package. ForwardingHandler simply forwards logging records to another logger elsewhere in the logging hierarchy. I like to think of this handler as a "softlink" for logging. The initialization method accepts the name of the logger object it should forward to, which is then fetched using getLogger(). This is preferrable to accepting the logger object itself because it's easier for a configuration file to reference another logger by its "qualname". If a name is not given to the initialization method, the handler will forward to the root logger. The emit method guards against infinite loops that would result from a logger object forwarding to itself (perhaps the result of misconfiguration). The attached file is not a "diff" file but just a code fragment that can be inserted somewhere in logging/__init__.py (or in logging/handlers.py with some minor modifications). ---------------------------------------------------------------------- >Comment By: Matthew F. Barnes (mfbarnes) Date: 2003-09-12 00:32 Message: Logged In: YES user_id=843448 The patch was motivated by an issue I see where a module has hard-coded a logger name into its logic, and an application would like to use that module as-is (e.g. a module from the standard library) but direct log messages from that module elsewhere in the logging hierarchy. The ForwardingHandler is intended to be a mechanism for doing so. The idea of using the same logger object at multiple points in the hierarchy is interesting and had not occurred to me, but it's not clear to me from the Python 2.3 documentation how to set that up (neither via the logging API nor from a configuration file), and I'm not sure if it addresses the issue I'm trying to resolve. You did identify some legitimate bugs in comments (1) and (2), and I've submitted a second patch which hopefully should address them. The bugs I've tried to address are defaulting to root, comparing a Handler instance to a Logger instance, and having the wrong logger name show up in the recipient's output. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-09-11 20:06 Message: Logged In: YES user_id=308438 I would make the following comments about this patch: 1. The logger name captures what happened/where it happened. If an event gets forwarded to a different logger, it just gets handled by that logger's handlers (assuming filtering lets it through), but is otherwise unchanged. If you forward an event from "asyncore" to "myapp.network.asyncore", the name would not change - it would get passed to "myapp.network.asyncore" handlers but still get emitted with a name of "asyncore". The same effect could be achieved by configuring handlers appropriately. Doing it this way, you could quite get easily get duplicated messages, which makes logs less useful. Particularly, the defaulting to the root logger is not a good idea - since many events filter up to the root logger, it would be very easy with the default to get lots of duplicated messages. 2. In ForwardingHandler.emit, self is a ForwardingHandler but self.recipient is a Logger. So the "if" condition will always evaluate to true. 3. Event loggers are the equivalent of "publish", and event handlers the equivalent of "subscribe". Mixing the two is not necessarily such a good idea. Events should be logged, by the developer, using a logger name which makes sense in the context of the module, subsystem or application. So, if an event occurs in "asyncore", we want to know that it happened in "asyncore". But if I want to see it interspersed with other stuff I'm doing in "myapp.network.asyncore", an application built on top of asyncore, I just add the same logger to "asyncore" and "myapp.network.asyncore", and I can see both sets of events together. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804180&group_id=5470 From noreply at sourceforge.net Thu Sep 11 23:33:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 12 01:33:59 2003 Subject: [Patches] [ python-Patches-804180 ] A ForwardingHandler for logging Message-ID: Patches item #804180, was opened at 2003-09-11 00:07 Message generated for change (Comment added) made by mfbarnes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804180&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthew F. Barnes (mfbarnes) Assigned to: Raymond Hettinger (rhettinger) Summary: A ForwardingHandler for logging Initial Comment: This was suggested recently on python-dev. I'm proposing it as an addition to the standard set of handlers in the logging package. ForwardingHandler simply forwards logging records to another logger elsewhere in the logging hierarchy. I like to think of this handler as a "softlink" for logging. The initialization method accepts the name of the logger object it should forward to, which is then fetched using getLogger(). This is preferrable to accepting the logger object itself because it's easier for a configuration file to reference another logger by its "qualname". If a name is not given to the initialization method, the handler will forward to the root logger. The emit method guards against infinite loops that would result from a logger object forwarding to itself (perhaps the result of misconfiguration). The attached file is not a "diff" file but just a code fragment that can be inserted somewhere in logging/__init__.py (or in logging/handlers.py with some minor modifications). ---------------------------------------------------------------------- >Comment By: Matthew F. Barnes (mfbarnes) Date: 2003-09-12 00:33 Message: Logged In: YES user_id=843448 The patch was motivated by an issue I see where a module has hard-coded a logger name into its logic, and an application would like to use that module as-is (e.g. a module from the standard library) but direct log messages from that module elsewhere in the logging hierarchy. The ForwardingHandler is intended to be a mechanism for doing so. The idea of using the same logger object at multiple points in the hierarchy is interesting and had not occurred to me, but it's not clear to me from the Python 2.3 documentation how to set that up (neither via the logging API nor from a configuration file), and I'm not sure if it addresses the issue I'm trying to resolve. You did identify some legitimate bugs in comments (1) and (2), and I've submitted a second patch which hopefully should address them. The bugs I've tried to address are defaulting to root, comparing a Handler instance to a Logger instance, and having the wrong logger name show up in the recipient's output. ---------------------------------------------------------------------- Comment By: Matthew F. Barnes (mfbarnes) Date: 2003-09-12 00:32 Message: Logged In: YES user_id=843448 The patch was motivated by an issue I see where a module has hard-coded a logger name into its logic, and an application would like to use that module as-is (e.g. a module from the standard library) but direct log messages from that module elsewhere in the logging hierarchy. The ForwardingHandler is intended to be a mechanism for doing so. The idea of using the same logger object at multiple points in the hierarchy is interesting and had not occurred to me, but it's not clear to me from the Python 2.3 documentation how to set that up (neither via the logging API nor from a configuration file), and I'm not sure if it addresses the issue I'm trying to resolve. You did identify some legitimate bugs in comments (1) and (2), and I've submitted a second patch which hopefully should address them. The bugs I've tried to address are defaulting to root, comparing a Handler instance to a Logger instance, and having the wrong logger name show up in the recipient's output. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-09-11 20:06 Message: Logged In: YES user_id=308438 I would make the following comments about this patch: 1. The logger name captures what happened/where it happened. If an event gets forwarded to a different logger, it just gets handled by that logger's handlers (assuming filtering lets it through), but is otherwise unchanged. If you forward an event from "asyncore" to "myapp.network.asyncore", the name would not change - it would get passed to "myapp.network.asyncore" handlers but still get emitted with a name of "asyncore". The same effect could be achieved by configuring handlers appropriately. Doing it this way, you could quite get easily get duplicated messages, which makes logs less useful. Particularly, the defaulting to the root logger is not a good idea - since many events filter up to the root logger, it would be very easy with the default to get lots of duplicated messages. 2. In ForwardingHandler.emit, self is a ForwardingHandler but self.recipient is a Logger. So the "if" condition will always evaluate to true. 3. Event loggers are the equivalent of "publish", and event handlers the equivalent of "subscribe". Mixing the two is not necessarily such a good idea. Events should be logged, by the developer, using a logger name which makes sense in the context of the module, subsystem or application. So, if an event occurs in "asyncore", we want to know that it happened in "asyncore". But if I want to see it interspersed with other stuff I'm doing in "myapp.network.asyncore", an application built on top of asyncore, I just add the same logger to "asyncore" and "myapp.network.asyncore", and I can see both sets of events together. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804180&group_id=5470 From noreply at sourceforge.net Fri Sep 12 00:31:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 12 02:31:47 2003 Subject: [Patches] [ python-Patches-804885 ] Lib/email/Encoders.py iso-2022 is 7bit Message-ID: Patches item #804885, was opened at 2003-09-12 06:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804885&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: Lib/email/Encoders.py iso-2022 is 7bit Initial Comment: In email package, all the raw encoding is assumed 8bit except us-ascii. This is not true for ISO-2022 series of encodings eg. iso-2022-jp, which use escape sequence for charset transition and all the characters including multibyte are 8th bit 0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804885&group_id=5470 From noreply at sourceforge.net Fri Sep 12 00:33:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 12 02:33:30 2003 Subject: [Patches] [ python-Patches-804885 ] Lib/email/Encoders.py iso-2022 is 7bit Message-ID: Patches item #804885, was opened at 2003-09-12 06:31 Message generated for change (Settings changed) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804885&group_id=5470 >Category: Library (Lib) >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: Lib/email/Encoders.py iso-2022 is 7bit Initial Comment: In email package, all the raw encoding is assumed 8bit except us-ascii. This is not true for ISO-2022 series of encodings eg. iso-2022-jp, which use escape sequence for charset transition and all the characters including multibyte are 8th bit 0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804885&group_id=5470 From noreply at sourceforge.net Fri Sep 12 02:19:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 12 04:19:56 2003 Subject: [Patches] [ python-Patches-804180 ] A ForwardingHandler for logging Message-ID: Patches item #804180, was opened at 2003-09-11 05:07 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804180&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthew F. Barnes (mfbarnes) Assigned to: Raymond Hettinger (rhettinger) Summary: A ForwardingHandler for logging Initial Comment: This was suggested recently on python-dev. I'm proposing it as an addition to the standard set of handlers in the logging package. ForwardingHandler simply forwards logging records to another logger elsewhere in the logging hierarchy. I like to think of this handler as a "softlink" for logging. The initialization method accepts the name of the logger object it should forward to, which is then fetched using getLogger(). This is preferrable to accepting the logger object itself because it's easier for a configuration file to reference another logger by its "qualname". If a name is not given to the initialization method, the handler will forward to the root logger. The emit method guards against infinite loops that would result from a logger object forwarding to itself (perhaps the result of misconfiguration). The attached file is not a "diff" file but just a code fragment that can be inserted somewhere in logging/__init__.py (or in logging/handlers.py with some minor modifications). ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-09-12 08:19 Message: Logged In: YES user_id=308438 I think/hope I understand the issue you're trying to address, and I think the existing API supports your use case. But your comment "The idea of using the same logger object at multiple points in the hierarchy is interesting and had not occurred to me" appears to mix up loggers and handlers. It's handlers which are attachable to multiple points in the hierarchy - loggers define the hierarchy. Loggers relate to events which occur in code - it's the developer's choice of logger name which indicates where in their scheme of things an event belongs. However, the audience of interested parties for the event is dynamic, and for that you need to use handlers, not loggers. To achieve the effect where you want a library module's logging output to be directed to your application's log, which is the use case you mention, add an appropriate handler (e.g. one which writes to your application's disk log file) to the module's logger. So, if a module has a logger accessible via a getCurrentLogger() function, you can say myAppLogFileHandler = FileHandler(...) module.getCurrentLogger().addHandler(myAppLogFileHandler) and then the module's events get logged to your application's log file. They will appear with the logger name specified by the module, making it very clear where the event originated. ---------------------------------------------------------------------- Comment By: Matthew F. Barnes (mfbarnes) Date: 2003-09-12 05:33 Message: Logged In: YES user_id=843448 The patch was motivated by an issue I see where a module has hard-coded a logger name into its logic, and an application would like to use that module as-is (e.g. a module from the standard library) but direct log messages from that module elsewhere in the logging hierarchy. The ForwardingHandler is intended to be a mechanism for doing so. The idea of using the same logger object at multiple points in the hierarchy is interesting and had not occurred to me, but it's not clear to me from the Python 2.3 documentation how to set that up (neither via the logging API nor from a configuration file), and I'm not sure if it addresses the issue I'm trying to resolve. You did identify some legitimate bugs in comments (1) and (2), and I've submitted a second patch which hopefully should address them. The bugs I've tried to address are defaulting to root, comparing a Handler instance to a Logger instance, and having the wrong logger name show up in the recipient's output. ---------------------------------------------------------------------- Comment By: Matthew F. Barnes (mfbarnes) Date: 2003-09-12 05:32 Message: Logged In: YES user_id=843448 The patch was motivated by an issue I see where a module has hard-coded a logger name into its logic, and an application would like to use that module as-is (e.g. a module from the standard library) but direct log messages from that module elsewhere in the logging hierarchy. The ForwardingHandler is intended to be a mechanism for doing so. The idea of using the same logger object at multiple points in the hierarchy is interesting and had not occurred to me, but it's not clear to me from the Python 2.3 documentation how to set that up (neither via the logging API nor from a configuration file), and I'm not sure if it addresses the issue I'm trying to resolve. You did identify some legitimate bugs in comments (1) and (2), and I've submitted a second patch which hopefully should address them. The bugs I've tried to address are defaulting to root, comparing a Handler instance to a Logger instance, and having the wrong logger name show up in the recipient's output. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-09-12 01:06 Message: Logged In: YES user_id=308438 I would make the following comments about this patch: 1. The logger name captures what happened/where it happened. If an event gets forwarded to a different logger, it just gets handled by that logger's handlers (assuming filtering lets it through), but is otherwise unchanged. If you forward an event from "asyncore" to "myapp.network.asyncore", the name would not change - it would get passed to "myapp.network.asyncore" handlers but still get emitted with a name of "asyncore". The same effect could be achieved by configuring handlers appropriately. Doing it this way, you could quite get easily get duplicated messages, which makes logs less useful. Particularly, the defaulting to the root logger is not a good idea - since many events filter up to the root logger, it would be very easy with the default to get lots of duplicated messages. 2. In ForwardingHandler.emit, self is a ForwardingHandler but self.recipient is a Logger. So the "if" condition will always evaluate to true. 3. Event loggers are the equivalent of "publish", and event handlers the equivalent of "subscribe". Mixing the two is not necessarily such a good idea. Events should be logged, by the developer, using a logger name which makes sense in the context of the module, subsystem or application. So, if an event occurs in "asyncore", we want to know that it happened in "asyncore". But if I want to see it interspersed with other stuff I'm doing in "myapp.network.asyncore", an application built on top of asyncore, I just add the same logger to "asyncore" and "myapp.network.asyncore", and I can see both sets of events together. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804180&group_id=5470 From noreply at sourceforge.net Fri Sep 12 06:42:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 12 08:42:09 2003 Subject: [Patches] [ python-Patches-804180 ] A ForwardingHandler for logging Message-ID: Patches item #804180, was opened at 2003-09-11 00:07 Message generated for change (Comment added) made by mfbarnes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804180&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthew F. Barnes (mfbarnes) Assigned to: Raymond Hettinger (rhettinger) Summary: A ForwardingHandler for logging Initial Comment: This was suggested recently on python-dev. I'm proposing it as an addition to the standard set of handlers in the logging package. ForwardingHandler simply forwards logging records to another logger elsewhere in the logging hierarchy. I like to think of this handler as a "softlink" for logging. The initialization method accepts the name of the logger object it should forward to, which is then fetched using getLogger(). This is preferrable to accepting the logger object itself because it's easier for a configuration file to reference another logger by its "qualname". If a name is not given to the initialization method, the handler will forward to the root logger. The emit method guards against infinite loops that would result from a logger object forwarding to itself (perhaps the result of misconfiguration). The attached file is not a "diff" file but just a code fragment that can be inserted somewhere in logging/__init__.py (or in logging/handlers.py with some minor modifications). ---------------------------------------------------------------------- >Comment By: Matthew F. Barnes (mfbarnes) Date: 2003-09-12 07:42 Message: Logged In: YES user_id=843448 Okay, perhaps I was misinterpreting the third item from your previous comment where you said: "But if I want to see it interspersed with other stuff I'm doing in "myapp.network.asyncore", an application built on top of asyncore, I just add the same logger to "asyncore" and "myapp.network.asyncore",and I can see both sets of events together." I guess it's not clear to me what you mean by "the same logger". Perhaps you meant "the same handler", which would be more in line with your most recent comments? ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-09-12 03:19 Message: Logged In: YES user_id=308438 I think/hope I understand the issue you're trying to address, and I think the existing API supports your use case. But your comment "The idea of using the same logger object at multiple points in the hierarchy is interesting and had not occurred to me" appears to mix up loggers and handlers. It's handlers which are attachable to multiple points in the hierarchy - loggers define the hierarchy. Loggers relate to events which occur in code - it's the developer's choice of logger name which indicates where in their scheme of things an event belongs. However, the audience of interested parties for the event is dynamic, and for that you need to use handlers, not loggers. To achieve the effect where you want a library module's logging output to be directed to your application's log, which is the use case you mention, add an appropriate handler (e.g. one which writes to your application's disk log file) to the module's logger. So, if a module has a logger accessible via a getCurrentLogger() function, you can say myAppLogFileHandler = FileHandler(...) module.getCurrentLogger().addHandler(myAppLogFileHandler) and then the module's events get logged to your application's log file. They will appear with the logger name specified by the module, making it very clear where the event originated. ---------------------------------------------------------------------- Comment By: Matthew F. Barnes (mfbarnes) Date: 2003-09-12 00:33 Message: Logged In: YES user_id=843448 The patch was motivated by an issue I see where a module has hard-coded a logger name into its logic, and an application would like to use that module as-is (e.g. a module from the standard library) but direct log messages from that module elsewhere in the logging hierarchy. The ForwardingHandler is intended to be a mechanism for doing so. The idea of using the same logger object at multiple points in the hierarchy is interesting and had not occurred to me, but it's not clear to me from the Python 2.3 documentation how to set that up (neither via the logging API nor from a configuration file), and I'm not sure if it addresses the issue I'm trying to resolve. You did identify some legitimate bugs in comments (1) and (2), and I've submitted a second patch which hopefully should address them. The bugs I've tried to address are defaulting to root, comparing a Handler instance to a Logger instance, and having the wrong logger name show up in the recipient's output. ---------------------------------------------------------------------- Comment By: Matthew F. Barnes (mfbarnes) Date: 2003-09-12 00:32 Message: Logged In: YES user_id=843448 The patch was motivated by an issue I see where a module has hard-coded a logger name into its logic, and an application would like to use that module as-is (e.g. a module from the standard library) but direct log messages from that module elsewhere in the logging hierarchy. The ForwardingHandler is intended to be a mechanism for doing so. The idea of using the same logger object at multiple points in the hierarchy is interesting and had not occurred to me, but it's not clear to me from the Python 2.3 documentation how to set that up (neither via the logging API nor from a configuration file), and I'm not sure if it addresses the issue I'm trying to resolve. You did identify some legitimate bugs in comments (1) and (2), and I've submitted a second patch which hopefully should address them. The bugs I've tried to address are defaulting to root, comparing a Handler instance to a Logger instance, and having the wrong logger name show up in the recipient's output. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-09-11 20:06 Message: Logged In: YES user_id=308438 I would make the following comments about this patch: 1. The logger name captures what happened/where it happened. If an event gets forwarded to a different logger, it just gets handled by that logger's handlers (assuming filtering lets it through), but is otherwise unchanged. If you forward an event from "asyncore" to "myapp.network.asyncore", the name would not change - it would get passed to "myapp.network.asyncore" handlers but still get emitted with a name of "asyncore". The same effect could be achieved by configuring handlers appropriately. Doing it this way, you could quite get easily get duplicated messages, which makes logs less useful. Particularly, the defaulting to the root logger is not a good idea - since many events filter up to the root logger, it would be very easy with the default to get lots of duplicated messages. 2. In ForwardingHandler.emit, self is a ForwardingHandler but self.recipient is a Logger. So the "if" condition will always evaluate to true. 3. Event loggers are the equivalent of "publish", and event handlers the equivalent of "subscribe". Mixing the two is not necessarily such a good idea. Events should be logged, by the developer, using a logger name which makes sense in the context of the module, subsystem or application. So, if an event occurs in "asyncore", we want to know that it happened in "asyncore". But if I want to see it interspersed with other stuff I'm doing in "myapp.network.asyncore", an application built on top of asyncore, I just add the same logger to "asyncore" and "myapp.network.asyncore", and I can see both sets of events together. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804180&group_id=5470 From noreply at sourceforge.net Fri Sep 12 09:47:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 12 09:47:48 2003 Subject: [Patches] [ python-Patches-804180 ] A ForwardingHandler for logging Message-ID: Patches item #804180, was opened at 2003-09-11 05:07 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804180&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthew F. Barnes (mfbarnes) Assigned to: Raymond Hettinger (rhettinger) Summary: A ForwardingHandler for logging Initial Comment: This was suggested recently on python-dev. I'm proposing it as an addition to the standard set of handlers in the logging package. ForwardingHandler simply forwards logging records to another logger elsewhere in the logging hierarchy. I like to think of this handler as a "softlink" for logging. The initialization method accepts the name of the logger object it should forward to, which is then fetched using getLogger(). This is preferrable to accepting the logger object itself because it's easier for a configuration file to reference another logger by its "qualname". If a name is not given to the initialization method, the handler will forward to the root logger. The emit method guards against infinite loops that would result from a logger object forwarding to itself (perhaps the result of misconfiguration). The attached file is not a "diff" file but just a code fragment that can be inserted somewhere in logging/__init__.py (or in logging/handlers.py with some minor modifications). ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-09-12 13:47 Message: Logged In: YES user_id=308438 Whoops, mea culpa. I typed "logger" when I meant "handler". Sorry to have caused confusion. ---------------------------------------------------------------------- Comment By: Matthew F. Barnes (mfbarnes) Date: 2003-09-12 12:42 Message: Logged In: YES user_id=843448 Okay, perhaps I was misinterpreting the third item from your previous comment where you said: "But if I want to see it interspersed with other stuff I'm doing in "myapp.network.asyncore", an application built on top of asyncore, I just add the same logger to "asyncore" and "myapp.network.asyncore",and I can see both sets of events together." I guess it's not clear to me what you mean by "the same logger". Perhaps you meant "the same handler", which would be more in line with your most recent comments? ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-09-12 08:19 Message: Logged In: YES user_id=308438 I think/hope I understand the issue you're trying to address, and I think the existing API supports your use case. But your comment "The idea of using the same logger object at multiple points in the hierarchy is interesting and had not occurred to me" appears to mix up loggers and handlers. It's handlers which are attachable to multiple points in the hierarchy - loggers define the hierarchy. Loggers relate to events which occur in code - it's the developer's choice of logger name which indicates where in their scheme of things an event belongs. However, the audience of interested parties for the event is dynamic, and for that you need to use handlers, not loggers. To achieve the effect where you want a library module's logging output to be directed to your application's log, which is the use case you mention, add an appropriate handler (e.g. one which writes to your application's disk log file) to the module's logger. So, if a module has a logger accessible via a getCurrentLogger() function, you can say myAppLogFileHandler = FileHandler(...) module.getCurrentLogger().addHandler(myAppLogFileHandler) and then the module's events get logged to your application's log file. They will appear with the logger name specified by the module, making it very clear where the event originated. ---------------------------------------------------------------------- Comment By: Matthew F. Barnes (mfbarnes) Date: 2003-09-12 05:33 Message: Logged In: YES user_id=843448 The patch was motivated by an issue I see where a module has hard-coded a logger name into its logic, and an application would like to use that module as-is (e.g. a module from the standard library) but direct log messages from that module elsewhere in the logging hierarchy. The ForwardingHandler is intended to be a mechanism for doing so. The idea of using the same logger object at multiple points in the hierarchy is interesting and had not occurred to me, but it's not clear to me from the Python 2.3 documentation how to set that up (neither via the logging API nor from a configuration file), and I'm not sure if it addresses the issue I'm trying to resolve. You did identify some legitimate bugs in comments (1) and (2), and I've submitted a second patch which hopefully should address them. The bugs I've tried to address are defaulting to root, comparing a Handler instance to a Logger instance, and having the wrong logger name show up in the recipient's output. ---------------------------------------------------------------------- Comment By: Matthew F. Barnes (mfbarnes) Date: 2003-09-12 05:32 Message: Logged In: YES user_id=843448 The patch was motivated by an issue I see where a module has hard-coded a logger name into its logic, and an application would like to use that module as-is (e.g. a module from the standard library) but direct log messages from that module elsewhere in the logging hierarchy. The ForwardingHandler is intended to be a mechanism for doing so. The idea of using the same logger object at multiple points in the hierarchy is interesting and had not occurred to me, but it's not clear to me from the Python 2.3 documentation how to set that up (neither via the logging API nor from a configuration file), and I'm not sure if it addresses the issue I'm trying to resolve. You did identify some legitimate bugs in comments (1) and (2), and I've submitted a second patch which hopefully should address them. The bugs I've tried to address are defaulting to root, comparing a Handler instance to a Logger instance, and having the wrong logger name show up in the recipient's output. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-09-12 01:06 Message: Logged In: YES user_id=308438 I would make the following comments about this patch: 1. The logger name captures what happened/where it happened. If an event gets forwarded to a different logger, it just gets handled by that logger's handlers (assuming filtering lets it through), but is otherwise unchanged. If you forward an event from "asyncore" to "myapp.network.asyncore", the name would not change - it would get passed to "myapp.network.asyncore" handlers but still get emitted with a name of "asyncore". The same effect could be achieved by configuring handlers appropriately. Doing it this way, you could quite get easily get duplicated messages, which makes logs less useful. Particularly, the defaulting to the root logger is not a good idea - since many events filter up to the root logger, it would be very easy with the default to get lots of duplicated messages. 2. In ForwardingHandler.emit, self is a ForwardingHandler but self.recipient is a Logger. So the "if" condition will always evaluate to true. 3. Event loggers are the equivalent of "publish", and event handlers the equivalent of "subscribe". Mixing the two is not necessarily such a good idea. Events should be logged, by the developer, using a logger name which makes sense in the context of the module, subsystem or application. So, if an event occurs in "asyncore", we want to know that it happened in "asyncore". But if I want to see it interspersed with other stuff I'm doing in "myapp.network.asyncore", an application built on top of asyncore, I just add the same logger to "asyncore" and "myapp.network.asyncore", and I can see both sets of events together. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804180&group_id=5470 From noreply at sourceforge.net Fri Sep 12 12:27:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 12 12:27:38 2003 Subject: [Patches] [ python-Patches-790000 ] Allow os.access to handle Unicode file name Message-ID: Patches item #790000, was opened at 2003-08-17 09:19 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790000&group_id=5470 Category: Windows Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Neil Hodgson (nyamatongwe) Assigned to: Martin v. L?wis (loewis) Summary: Allow os.access to handle Unicode file name Initial Comment: Patch to fix bug 789995 and unit test for fix. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-12 18:27 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as test_pep277.py 1.8 posixmodule.c 2.303 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790000&group_id=5470 From noreply at sourceforge.net Fri Sep 12 12:38:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 12 12:38:37 2003 Subject: [Patches] [ python-Patches-793021 ] implement htmllib.HTMLParser.reset Message-ID: Patches item #793021, was opened at 2003-08-22 10:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793021&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Andrew Gaul (gaul) Assigned to: Martin v. L?wis (loewis) Summary: implement htmllib.HTMLParser.reset Initial Comment: Fixes bug 711632. htmllib.HTMLParser.reset is not defined and calls its superclass, SGMLParser.reset. This does not reset the HTMLParser state. Patch defines HTMLParser.reset and moves HTMLParser.__init__ code into it. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-12 18:38 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as htmllib.py 1.19.16.1, 1.20 NEWS 1.831.4.40 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793021&group_id=5470 From noreply at sourceforge.net Sat Sep 13 09:56:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 13 09:56:44 2003 Subject: [Patches] [ python-Patches-805604 ] fix --without-threads Message-ID: Patches item #805604, was opened at 2003-09-13 15:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805604&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: fix --without-threads Initial Comment: Currently, Pyhton builds always against libpthread on systems that have sem_init in libpthread. Even if configure was invoked --without-threads. The patch changes this behaviour to only check for sem_init if python will be built with threads (with_threads = "yes or empty). Second, on systems that support a compiler switch for thread support (eg. -pthread) and have C++ support CXX will always set to CXX + flag, even in the unthreaded case. The patch fixes that. The patch is against release23-maint. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805604&group_id=5470 From noreply at sourceforge.net Sat Sep 13 10:15:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 13 10:15:40 2003 Subject: [Patches] [ python-Patches-805613 ] PTH related fixes Message-ID: Patches item #805613, was opened at 2003-09-13 16:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805613&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: PTH related fixes Initial Comment: Some PTH fixes with have in NetBSD's pkgsrc for a some time now. They're needed on NetBSD <= 1.6.x for Python + PTH to run properly. (And probably on other systems using PTH, too.) Basically the stack-size of PTH is way too small and _POSIX_THREADS shouldn't be defined. The patch is against release23-maint. Note: I'm not the original autor of this patch. I have permission to submit it, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805613&group_id=5470 From noreply at sourceforge.net Sat Sep 13 10:54:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 13 10:54:14 2003 Subject: [Patches] [ python-Patches-805626 ] make test_fcntl 64bit clean Message-ID: Patches item #805626, was opened at 2003-09-13 16:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805626&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: make test_fcntl 64bit clean Initial Comment: Patch to make test_fcntl.py 64bit clean (from NetBSD's pkgsrc) The patch is against release23-maint. Note: I'm not the original autor of this patch. I have permission to submit it, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805626&group_id=5470 From noreply at sourceforge.net Sat Sep 13 12:53:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 13 12:53:38 2003 Subject: [Patches] [ python-Patches-805678 ] Fix linking with shared libpython Message-ID: Patches item #805678, was opened at 2003-09-13 18:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805678&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: Fix linking with shared libpython Initial Comment: If Python is build with a shared lib python it installs a libpython2.3.so.1.0 ( $(INSTSONAME) ). If Python is not installed into a standard dir (eg. /usr), for example $HOME/python this library is not found by the linker. Meaning this fails: gcc -L$HOME/lib -o myprog -lpython2.3 This fails because there is no "libpython2.3.so". If Python is installed into standard dirs - on Linux - this is handled by "ldconfig", but not for non-standard dirs or other unixes where ldconfig doesn't create the .so link. The attached patch fixes this by creating the needed symlink at install time. Tested Linux and NetBSD. The patch is against release23-maint. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805678&group_id=5470 From noreply at sourceforge.net Sat Sep 13 21:29:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 13 21:29:50 2003 Subject: [Patches] [ python-Patches-805830 ] Highlight builtins Message-ID: Patches item #805830, was opened at 2003-09-14 11:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805830&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nigel Rowe (fisheggs) Assigned to: Nobody/Anonymous (nobody) Summary: Highlight builtins Initial Comment: There was a recent discussion on c.l.p regarding shadowing builtins. (Summary, DONT). The point was made that decent editors should highlight builtins and keywords. The attached patch enables hightlighting of all entries in __builtin__ excluding those starting with a '_' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805830&group_id=5470 From noreply at sourceforge.net Sat Sep 13 22:39:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 13 22:39:45 2003 Subject: [Patches] [ python-Patches-805830 ] Highlight builtins Message-ID: Patches item #805830, was opened at 2003-09-13 20:29 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805830&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nigel Rowe (fisheggs) >Assigned to: Kurt B. Kaiser (kbk) Summary: Highlight builtins Initial Comment: There was a recent discussion on c.l.p regarding shadowing builtins. (Summary, DONT). The point was made that decent editors should highlight builtins and keywords. The attached patch enables hightlighting of all entries in __builtin__ excluding those starting with a '_' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805830&group_id=5470 From noreply at sourceforge.net Sun Sep 14 09:57:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 14 09:58:11 2003 Subject: [Patches] [ python-Patches-805976 ] Tkconstants.py - listbox activestyle constants Message-ID: Patches item #805976, was opened at 2003-09-14 14:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805976&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: Tkconstants.py - listbox activestyle constants Initial Comment: This patch adds 2 constants to Tkconstants.py which can be used to set a listbox's activestyle option (added in Tk8.4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805976&group_id=5470 From noreply at sourceforge.net Sun Sep 14 19:52:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 14 19:52:51 2003 Subject: [Patches] [ python-Patches-806246 ] use basestring where possible Message-ID: Patches item #806246, was opened at 2003-09-15 08:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=806246&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: use basestring where possible Initial Comment: This patch replaces isinstance(foo, (str, unicode)) with isinstance(foo, basestring). This will make the scripts cleaner, faster and less error prone. Apparently, this patch applies to Python >= 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=806246&group_id=5470 From noreply at sourceforge.net Mon Sep 15 14:31:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 15 14:31:54 2003 Subject: [Patches] [ python-Patches-804212 ] unittest's main don't handle TestSuite in command line Message-ID: Patches item #804212, was opened at 2003-09-11 01:52 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804212&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) >Assigned to: Steve Purcell (purcell) Summary: unittest's main don't handle TestSuite in command line Initial Comment: When using unittest's "main" it fails if in the command line a name of TestSuite class is given. Suppose ts.py is: ---- #!/usr/bin/env python from unittest import TestCase, makeSuite, main class T(TestCase): def test_moo(self): self.fail() test_suite = makeSuite(T, "test_") if __name__ == "__main__": main() ---- Then running "ts.py test_suite" will fail. Attached is a patch for unittest.py Miki ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804212&group_id=5470 From noreply at sourceforge.net Mon Sep 15 16:47:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 15 16:48:00 2003 Subject: [Patches] [ python-Patches-806800 ] NetBSD py_curses.h fix Message-ID: Patches item #806800, was opened at 2003-09-15 22:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=806800&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: NetBSD py_curses.h fix Initial Comment: On NetBSD, [n]curses.h and stdlib.h/wchar.h use different guards against multiple definition of wchar_t and wint_t. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=806800&group_id=5470 From noreply at sourceforge.net Tue Sep 16 15:13:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 16 15:13:33 2003 Subject: [Patches] [ python-Patches-807334 ] Prevent duplicate warnings filters Message-ID: Patches item #807334, was opened at 2003-09-16 14:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=807334&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Jeremy Hylton (jhylton) Summary: Prevent duplicate warnings filters Initial Comment: Multiple registration of the same filter contributes no value but causes unnecessary growing reference counts for repeated tests. Also, the duplicates slow down the already excrutiatingly slow warning.warn() which now appears throughout the codebase. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=807334&group_id=5470 From noreply at sourceforge.net Tue Sep 16 17:47:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 16 17:47:25 2003 Subject: [Patches] [ python-Patches-774665 ] making Python LC_NUMERIC agnostic Message-ID: Patches item #774665, was opened at 2003-07-20 20:39 Message generated for change (Comment added) made by gustavo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=774665&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo J. A. M. Carneiro (gustavo) Assigned to: Nobody/Anonymous (nobody) Summary: making Python LC_NUMERIC agnostic Initial Comment: This patch offers conversion string<->float conversion functions that are locale agnostic. This way, Python will be able to run perfectly even when LC_NUMERIC is set to something other than C. It happens frequently when using external modules that these modules change LC_NUMERIC without python knowing about it. It will never stop happening, unfortunately, so it is best to make python not depend on LC_NUMERIC being always set to 'C'. ---------------------------------------------------------------------- >Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2003-09-16 22:47 Message: Logged In: YES user_id=908 Used James Henstridge's cleaned up code, and cleaned it up a bit more. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-22 20:49 Message: Logged In: YES user_id=21627 I don't think the problem can be solved once and forall. In fact, I'm certain that the glib code is incorrect on some systems. For example, has it been tested on VMS, with its three different floatin point formats? I don't know whether linking with glib is a good idea. I'd happily accept a patch that supports glibc only, or one that tries for fall back to C++ std::locale on systems that support linking C++ code into C applications. Since the bug report was triggered through gtk problems, I expect that these can all be solved by linking with glib - using glib on a gtk installation should work fine. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2003-07-22 17:26 Message: Logged In: YES user_id=908 If neither glib nor glibc are available, are we still allowed to change LC_NUMERIC at will? I want to get rid of this problem once and for all. The next step is to change LC_NUMERIC to the correct locale value (or better, not change it to 'C'). Anyway, are you sure it's a good idea to link to glib? Is it a good idea to make the python interpreter depend on glib? Perhaps it is a bigger library than you think... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-21 22:52 Message: Logged In: YES user_id=21627 On some systems, the desired behaviour just is not implementable. On such systems, we should not try to implement it by replacing the standard library. Instead, we should just give in and not implement the feature. People using such systems should convince their system vendors to provide the proper API, or find out whether proper API already exists. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2003-07-21 11:06 Message: Logged In: YES user_id=908 I have to incorporate glib code, otherwise what happens if glib is not installed? It is my intention that the current behaviour *never* be preserved. Well, that's not exactly an accurate statement. What I mean is that str() and float() should keep the current C-locale behaviour. However, underneath these python functions we could have LC_NUMERIC set something other than 'C'. This is vital for some modules, like GTK+, that depend on LC_NUMERIC to be set the locale dependent value, otherwise it behaves different from what the user expects. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-20 22:25 Message: Logged In: YES user_id=21627 I recommend that you do not incorporate the code of glib, but rather arrange to link with glib (perhaps only if activated by --with-glib). If no guaranteed-C-locale strtod is available, the current behaviour should be preserved. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=774665&group_id=5470 From noreply at sourceforge.net Wed Sep 17 01:20:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 17 01:20:47 2003 Subject: [Patches] [ python-Patches-788509 ] Glossary Message-ID: Patches item #788509, was opened at 2003-08-13 23:04 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788509&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Glossary Initial Comment: The topic of iterables came up on c.l.py recently. One of the participants mentioned that "iterable" isn't listed in the index of either the language or library reference manuals. A quick search didn't yield any obvious definition of what an iterable is. (There may be something I missed. I wasn't terribly thorough in my search.) The attached patch attempts to fix that omission by adding a glossary to the language reference manual. Maybe it should be a separate manual. It doesn't seem like it belongs in the tutorial, and the library reference manual doesn't cover the language itself. Keep, toss, throw darts at, or pass back for action. S ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-17 00:20 Message: Logged In: YES user_id=80475 The wiki was a success and the glossary looks ready for prime-time. So go ahead and add it (or assign to me). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-14 08:29 Message: Logged In: YES user_id=44345 Agreed. Any glossary with only one entry would be a bit thin. Thanks for the new entry. :-) ---------------------------------------------------------------------- Comment By: Duncan Booth (duncanb) Date: 2003-08-14 03:33 Message: Logged In: YES user_id=74031 Sorry, but I'm going to throw darts at this. You need to have glossary entries for both 'iterable' and 'iterator', and you're current definition of 'iterable' is actually the definition of 'iterator' not of 'iterable'. Try something like this: \index{iterable{ \item[iterable] Any object which supports enumeration of a set of values by calling its \method{__iter__} which returns an iterator over those values. Examples include \class{file}, \class{list} and \class{dict} objects. In the case of \class {dict} objects, iteration is over the keys in the object. \index{iterator} \item[iterator] An object which supports enumeration of a set of values by calling its \method{next} method and which contains an \method{__iter__} method which returns the object itself. Examples: \class{file} is a iterable which is its own iterator. \class{list} and \class{dict} are iterables which create iterators of types which are not otherwise visible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788509&group_id=5470 From noreply at sourceforge.net Wed Sep 17 01:52:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 17 01:52:19 2003 Subject: [Patches] [ python-Patches-806246 ] use basestring where possible Message-ID: Patches item #806246, was opened at 2003-09-14 18:52 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=806246&group_id=5470 Category: Library (Lib) >Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: use basestring where possible Initial Comment: This patch replaces isinstance(foo, (str, unicode)) with isinstance(foo, basestring). This will make the scripts cleaner, faster and less error prone. Apparently, this patch applies to Python >= 2.3. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-17 00:52 Message: Logged In: YES user_id=80475 Applied the change for doctest, pkgutil, and test.test_textwrap. csv needs to remain Py2.2 compatible. I'm not inclined to change anything in the platmac tree because that group of users is highly sensitive to small changes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=806246&group_id=5470 From noreply at sourceforge.net Wed Sep 17 10:50:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 17 10:50:39 2003 Subject: [Patches] [ python-Patches-788509 ] Glossary Message-ID: Patches item #788509, was opened at 2003-08-13 23:04 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788509&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Glossary Initial Comment: The topic of iterables came up on c.l.py recently. One of the participants mentioned that "iterable" isn't listed in the index of either the language or library reference manuals. A quick search didn't yield any obvious definition of what an iterable is. (There may be something I missed. I wasn't terribly thorough in my search.) The attached patch attempts to fix that omission by adding a glossary to the language reference manual. Maybe it should be a separate manual. It doesn't seem like it belongs in the tutorial, and the library reference manual doesn't cover the language itself. Keep, toss, throw darts at, or pass back for action. S ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-09-17 09:50 Message: Logged In: YES user_id=44345 Agreed, it has been quite successful. Fred, I'll take this over if you like, but I'd sort of like a pronouncement about where the glossary should go. My thought was that it would be an appendix to the language reference manual. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-17 00:20 Message: Logged In: YES user_id=80475 The wiki was a success and the glossary looks ready for prime-time. So go ahead and add it (or assign to me). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-14 08:29 Message: Logged In: YES user_id=44345 Agreed. Any glossary with only one entry would be a bit thin. Thanks for the new entry. :-) ---------------------------------------------------------------------- Comment By: Duncan Booth (duncanb) Date: 2003-08-14 03:33 Message: Logged In: YES user_id=74031 Sorry, but I'm going to throw darts at this. You need to have glossary entries for both 'iterable' and 'iterator', and you're current definition of 'iterable' is actually the definition of 'iterator' not of 'iterable'. Try something like this: \index{iterable{ \item[iterable] Any object which supports enumeration of a set of values by calling its \method{__iter__} which returns an iterator over those values. Examples include \class{file}, \class{list} and \class{dict} objects. In the case of \class {dict} objects, iteration is over the keys in the object. \index{iterator} \item[iterator] An object which supports enumeration of a set of values by calling its \method{next} method and which contains an \method{__iter__} method which returns the object itself. Examples: \class{file} is a iterable which is its own iterator. \class{list} and \class{dict} are iterables which create iterators of types which are not otherwise visible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788509&group_id=5470 From noreply at sourceforge.net Wed Sep 17 11:45:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 17 11:45:45 2003 Subject: [Patches] [ python-Patches-788509 ] Glossary Message-ID: Patches item #788509, was opened at 2003-08-13 23:04 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788509&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Glossary Initial Comment: The topic of iterables came up on c.l.py recently. One of the participants mentioned that "iterable" isn't listed in the index of either the language or library reference manuals. A quick search didn't yield any obvious definition of what an iterable is. (There may be something I missed. I wasn't terribly thorough in my search.) The attached patch attempts to fix that omission by adding a glossary to the language reference manual. Maybe it should be a separate manual. It doesn't seem like it belongs in the tutorial, and the library reference manual doesn't cover the language itself. Keep, toss, throw darts at, or pass back for action. S ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-17 10:45 Message: Logged In: YES user_id=80475 I recommend putting it in the tutorial. As it stands now, the glossary can be profitability read A to Z after completing the tutorial. It can serve to unify and solidify the ideas presented up to that point. The reference manual is more encyclopedic and I think the glossary would be lost in a sea of entries. Another alternative is to make it a stand-alone link from the main page: Tutorial (start here) Ref Manual Lib Ref Glossary of Key Concepts This patch is marked for Py2.4. I recommend that it be added to Py2.3.1 also. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-17 09:50 Message: Logged In: YES user_id=44345 Agreed, it has been quite successful. Fred, I'll take this over if you like, but I'd sort of like a pronouncement about where the glossary should go. My thought was that it would be an appendix to the language reference manual. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-17 00:20 Message: Logged In: YES user_id=80475 The wiki was a success and the glossary looks ready for prime-time. So go ahead and add it (or assign to me). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-14 08:29 Message: Logged In: YES user_id=44345 Agreed. Any glossary with only one entry would be a bit thin. Thanks for the new entry. :-) ---------------------------------------------------------------------- Comment By: Duncan Booth (duncanb) Date: 2003-08-14 03:33 Message: Logged In: YES user_id=74031 Sorry, but I'm going to throw darts at this. You need to have glossary entries for both 'iterable' and 'iterator', and you're current definition of 'iterable' is actually the definition of 'iterator' not of 'iterable'. Try something like this: \index{iterable{ \item[iterable] Any object which supports enumeration of a set of values by calling its \method{__iter__} which returns an iterator over those values. Examples include \class{file}, \class{list} and \class{dict} objects. In the case of \class {dict} objects, iteration is over the keys in the object. \index{iterator} \item[iterator] An object which supports enumeration of a set of values by calling its \method{next} method and which contains an \method{__iter__} method which returns the object itself. Examples: \class{file} is a iterable which is its own iterator. \class{list} and \class{dict} are iterables which create iterators of types which are not otherwise visible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788509&group_id=5470 From noreply at sourceforge.net Wed Sep 17 13:51:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 17 13:51:57 2003 Subject: [Patches] [ python-Patches-762934 ] address test_time.py failures under Redhat 6.2 Message-ID: Patches item #762934, was opened at 2003-06-29 17:44 Message generated for change (Comment added) made by furie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762934&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Brett Cannon (bcannon) Summary: address test_time.py failures under Redhat 6.2 Initial Comment: A mangled version of this patch is also in bug: http://www.python.org/sf/728051 Looks like tzset(3) is broken under Redhat 6.2 in a way that wasn't being detected by configure. This patch adds stricter tzset(3) checking to configure.in. ---------------------------------------------------------------------- Comment By: Jordan Krushen (furie) Date: 2003-09-17 10:51 Message: Logged In: YES user_id=218883 I've tested kbk's patch on fresh installs of both RH 6.1 and 6. 2, and they both pass all (non-skipped) tests. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-07 20:11 Message: Logged In: YES user_id=357491 OK, so Kurt's thinking and debugging all seem good to me. I applied the patch and it worked correctly for me. Can other people test it (not just Red Hat but also other platforms; OS X is covered by my test)? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-24 23:48 Message: Logged In: YES user_id=357491 Thanks for the debugging work, Kurt. I will take a good look at this when 2.4 dev starts. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-24 20:48 Message: Logged In: YES user_id=149084 [kbk@float ~/PYSRC]$ ./python Python 2.3c2 (#15, Jul 24 2003, 11:17:16) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> from os import environ >>> victoria = 'AEST-10AEDT-11,M10.5.0,M3.5.0' >>> environ['TZ'] = victoria >>> time.tzset() >>> time.tzname ('AEST', 'AEST') >>> ========================================= Hm!! Try a couple of things to try to see what's going on: ========================================= >>> victoria2 = 'AEST-10AEDT-11' >>> environ['TZ'] = victoria2 >>> time.tzset() >>> time.tzname ('AEST', 'AEDT') >>> >>> # try reversing the changeover ... >>> victoria3 = 'AEST-10AEDT-11,M3.5.0,M10.5.0' >>> environ['TZ'] = victoria3 >>> time.tzset() >>> time.tzname ('AEST', 'AEDT') =================================== ok, debug inittimezone: =================================== Breakpoint 1, inittimezone (m=0x4014053c) at /home/kbk/PYTHON/python/dist/src/Modules/timemodule.c:608 608t = (time((time_t *)0) / YEAR) * YEAR; (gdb) n 609p = localtime(&t); (gdb) p asctime(localtime(&t)) $14 = 0x4013be00 "Wed Jan 1 16:00:00 2003\n" (gdb) p localtime(&t)->tm_zone $19 = 0x8162b78 "AEST" [std time on Jan 1!! ...back up a day or so....] (gdb) p t = t - 84000 $20 = 1041316800 (gdb) p localtime(&t)->tm_zone $21 = 0x8162b90 "AEDT" (gdb) p asctime(localtime(&t)) $22 = 0x4013be00 "Tue Dec 31 17:40:00 2002\n" (gdb) =================================== so Linux6.2 thinks AEDT switches to AEST in Jan, and six months forward is still AEST. xmas2002 is AEDT so config test passes but timemodule uses Jan 1 and flubs when setting tzname. Need to do the config test later than xmas. ===================================== *** Apply Patch SF 762934 configure.in.patch.kbk ====================================== autoreconf && ./configure && make clean && make OPT=-g ====================================== extract from configure log: .... checking for broken nice()... yes checking for working tzset()... no checking for tv_nsec in struct stat... no checking whether mvwdelch is an expression... yes .... ====================================== [kbk@float ~/PYSRC]$ ./python Python 2.3c2 (#18, Jul 24 2003, 22:40:09) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from test import test_time >>> test_time.test_main() test_asctime (test.test_time.TimeTestCase) ... ok test_clock (test.test_time.TimeTestCase) ... ok test_conversions (test.test_time.TimeTestCase) ... ok test_data_attributes (test.test_time.TimeTestCase) ... ok test_sleep (test.test_time.TimeTestCase) ... ok test_strftime (test.test_time.TimeTestCase) ... ok test_strptime (test.test_time.TimeTestCase) ... ok test_tzset (test.test_time.TimeTestCase) ... ok ------------------------------------------------------------ Ran 8 tests in 2.523s OK >>> =================================== make test: =================================== .... .... test_zlib 227 tests OK. 28 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl test_curses test_email_codecs test_gl test_imgfile test_largefile test_linuxaudiodev test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound Those skips are all expected on linux2. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-22 16:04 Message: Logged In: YES user_id=357491 Well, it is looking like tzset_AEST is not working as a solution. Hopefully Neal's patch will do the trick. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-22 15:46 Message: Logged In: YES user_id=33168 See this mail for a possible fix. http://mail.python.org/pipermail/python-dev/2003-July/037116.html Stuart, is that correct? It fixes the problem on RedHat 6.2 and doesn't break on RedHat 9. The change is to define YEAR as 365 * 24 * 3600, instead of adding 6 hours. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-16 13:05 Message: Logged In: YES user_id=44345 Works for me (Mac OS X) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-12 19:27 Message: Logged In: YES user_id=357491 Quick update: I got autoreconf to work and it seems to work for me. I also tested the C code in isolation and had no problems. So I now I just need other people to apply the patch and say whether it works. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-12 16:01 Message: Logged In: YES user_id=357491 Well, it didn't work for two people for Red Hat 6.2 . Perhaps being more explicit for the test? To give that a shot, I am uploading a patch that tests explicitly for AEDT as the daylight-savings timezone. I snagged the code mostly from Modules/timemodule.c . Now this is untested so there could be syntax problems. I can't get a proper version of Autoconf to run on my system so I can run autoreconf. Hopefully this will deal with the problem. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-10 07:29 Message: Logged In: YES user_id=12800 This patch didn't break RH9. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-03 13:16 Message: Logged In: YES user_id=357491 We can say it should fail under Linux, but we can't specify Red Hat 6.2. I am keeping an eye on this patch for bug #763153, but I have to wait until the OP applies it and tests it. Looking at the patch, beyond not realizing that the X-mas time was GMT initially and the unneeded variable assignments, the patch looks fine to me (might want to comment that tzset does not return a value; rather non-standard) although I am no autoconf expert and I am assuming it just compiles this C code and any problems it just says it fails. Neal, what OS are you running? If it is non-OS X (sorry, that's what I am running as well) can you give the patch a try? ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-07-01 20:51 Message: Logged In: YES user_id=46639 This patch has only been tested under OS X. I'm confident that it won't break other platforms. I have no real way of proving that it addresses the problem it is supposed to solve, however, as I don't have access to a box that fails the tzset test in test_time.py. The only reported platform that this is failing on is at http://www.python.org/sf/728051, so we could just flag this test as expected to fail on that platform, if someone knows how to do that. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-01 20:03 Message: Logged In: YES user_id=33168 Stuart, what boxes did you test this on? How confident are you that this won't break some other platform? I'm asking to try to determine if this should go into 2.3final (we only have 1 release candidate before release) or if this should wait for 2.3.1. Thanks for all your work on tzset. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762934&group_id=5470 From noreply at sourceforge.net Wed Sep 17 16:20:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 17 16:20:43 2003 Subject: [Patches] [ python-Patches-808115 ] Add script support to bdist_rpm.py Message-ID: Patches item #808115, was opened at 2003-09-17 16:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=808115&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Campbell (tcampbell) Assigned to: Nobody/Anonymous (nobody) Summary: Add script support to bdist_rpm.py Initial Comment: bdist_rpm is missing the configuration values that allow a package developer to specify scripts to override each phase of the rpm build process. The defaults are always used, as the command line arguments are not supported. This patch adds support for that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=808115&group_id=5470 From noreply at sourceforge.net Wed Sep 17 16:28:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 17 16:29:04 2003 Subject: [Patches] [ python-Patches-808120 ] Add --force-arch=ARCH to bdist_rpm.py Message-ID: Patches item #808120, was opened at 2003-09-17 16:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=808120&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Campbell (tcampbell) Assigned to: Nobody/Anonymous (nobody) Summary: Add --force-arch=ARCH to bdist_rpm.py Initial Comment: Allow a package builder to override the default architecture detection method employed by distutils by specifying --force-arch=ARCH on the command line; e.g., --force-arch=ppc This affects the BuildArch: tag in the resulting spec file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=808120&group_id=5470 From noreply at sourceforge.net Wed Sep 17 16:40:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 17 16:40:32 2003 Subject: [Patches] [ python-Patches-808129 ] Change --changelog to accept files Message-ID: Patches item #808129, was opened at 2003-09-17 16:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=808129&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Campbell (tcampbell) Assigned to: Nobody/Anonymous (nobody) Summary: Change --changelog to accept files Initial Comment: It's more useful to track changes by including a changelog file than adding a single string to the command line. A changelog file should be formatted to included without change into an rpm specfile -- and may contain one or more entries, constituting the history of the package. This gets dumped into the %changelog section of the intermediate spec-file. For example; a file called ChangeLog could have the following contents, which would then be propogated to the actual rpm by adding --changelog=ChangeLog to the command line. * Wed 17 Sep 2003 Tony Campbell - ported to ppc - another message * Tue Aug 19 2003 Tony Campbell - Created ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=808129&group_id=5470 From noreply at sourceforge.net Wed Sep 17 18:48:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 17 18:48:47 2003 Subject: [Patches] [ python-Patches-808210 ] fix for external test regression in test.regrtest Message-ID: Patches item #808210, was opened at 2003-09-17 17:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=808210&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nicholas Riley (nriley) Assigned to: Nobody/Anonymous (nobody) Summary: fix for external test regression in test.regrtest Initial Comment: A detailed description of the bug introduced in Python 2.3 is here: http://sourceforge.net/tracker/index.php? func=detail&aid=798274&group_id=5470&atid=105470 This patch implements the solution as suggested in the report: if a testdir argument is provided and the test module is not in a package, it attempts to import modules from that directory. This restores compatibility with the test suites I wrote in Python 2.2, and does not interfere with the current behavior as used by the Python regression test suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=808210&group_id=5470 From noreply at sourceforge.net Thu Sep 18 03:15:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 18 03:15:26 2003 Subject: [Patches] [ python-Patches-808362 ] typo fix for unittest and timeit Message-ID: Patches item #808362, was opened at 2003-09-18 16:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=808362&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: typo fix for unittest and timeit Initial Comment: I've found two typos in the library docs. #1 [10.10.1 Command Line Interface] www.python.org/dev/doc/devel/lib/node396.html > the default timer functions measures wall clock time this should read > the default timer functions measure wall clock time The same line can be found in Lib/timeit.py, so this also needs to be fixed. #2 [5.3.7 TestResult Objects] www.python.org/dev/doc/devel/lib/testresult- objects.html > and mmay be extended ... this should read > and may be extended ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=808362&group_id=5470 From noreply at sourceforge.net Thu Sep 18 14:33:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 18 14:33:51 2003 Subject: [Patches] [ python-Patches-806800 ] NetBSD py_curses.h fix Message-ID: Patches item #806800, was opened at 2003-09-15 22:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=806800&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: NetBSD py_curses.h fix Initial Comment: On NetBSD, [n]curses.h and stdlib.h/wchar.h use different guards against multiple definition of wchar_t and wint_t. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-18 20:33 Message: Logged In: YES user_id=21627 That is a work around a NetBSD bug, right? If so, there should be some procedure to retest presence of the bug in new NetBSD releases, and record the versions for which the bug has been found to be present. Then, when the newest release with the bug is not supported in Python anymore, the code can be removed (which might well be 10 years from now). If possible, a code fragment like #if (NetBSD_major == 3) or (NetBSD_major==4) // bug present, add work-around #else #error Please check whether the bug is still present #endif ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=806800&group_id=5470 From noreply at sourceforge.net Thu Sep 18 14:34:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 18 14:34:11 2003 Subject: [Patches] [ python-Patches-805976 ] Tkconstants.py - listbox activestyle constants Message-ID: Patches item #805976, was opened at 2003-09-14 15:57 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805976&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) >Assigned to: Martin v. L?wis (loewis) Summary: Tkconstants.py - listbox activestyle constants Initial Comment: This patch adds 2 constants to Tkconstants.py which can be used to set a listbox's activestyle option (added in Tk8.4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805976&group_id=5470 From noreply at sourceforge.net Thu Sep 18 14:40:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 18 14:40:56 2003 Subject: [Patches] [ python-Patches-805678 ] Fix linking with shared libpython Message-ID: Patches item #805678, was opened at 2003-09-13 18:53 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805678&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) >Assigned to: Martin v. L?wis (loewis) Summary: Fix linking with shared libpython Initial Comment: If Python is build with a shared lib python it installs a libpython2.3.so.1.0 ( $(INSTSONAME) ). If Python is not installed into a standard dir (eg. /usr), for example $HOME/python this library is not found by the linker. Meaning this fails: gcc -L$HOME/lib -o myprog -lpython2.3 This fails because there is no "libpython2.3.so". If Python is installed into standard dirs - on Linux - this is handled by "ldconfig", but not for non-standard dirs or other unixes where ldconfig doesn't create the .so link. The attached patch fixes this by creating the needed symlink at install time. Tested Linux and NetBSD. The patch is against release23-maint. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805678&group_id=5470 From noreply at sourceforge.net Thu Sep 18 14:48:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 18 14:48:21 2003 Subject: [Patches] [ python-Patches-805626 ] make test_fcntl 64bit clean Message-ID: Patches item #805626, was opened at 2003-09-13 16:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805626&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: make test_fcntl 64bit clean Initial Comment: Patch to make test_fcntl.py 64bit clean (from NetBSD's pkgsrc) The patch is against release23-maint. Note: I'm not the original autor of this patch. I have permission to submit it, though. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-18 20:48 Message: Logged In: YES user_id=21627 Does the patch work on all systems? For both byte orders? On both 32-bit and 64-bit systems? I'm particularly concerned about big-endian 32-bit systems, as the padding apparently is intended for little-endian systems only. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805626&group_id=5470 From noreply at sourceforge.net Thu Sep 18 14:51:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 18 14:51:20 2003 Subject: [Patches] [ python-Patches-805613 ] PTH related fixes Message-ID: Patches item #805613, was opened at 2003-09-13 16:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805613&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: PTH related fixes Initial Comment: Some PTH fixes with have in NetBSD's pkgsrc for a some time now. They're needed on NetBSD <= 1.6.x for Python + PTH to run properly. (And probably on other systems using PTH, too.) Basically the stack-size of PTH is way too small and _POSIX_THREADS shouldn't be defined. The patch is against release23-maint. Note: I'm not the original autor of this patch. I have permission to submit it, though. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-18 20:51 Message: Logged In: YES user_id=21627 Is pth actively being used on that system? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805613&group_id=5470 From noreply at sourceforge.net Thu Sep 18 14:51:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 18 14:51:58 2003 Subject: [Patches] [ python-Patches-805604 ] fix --without-threads Message-ID: Patches item #805604, was opened at 2003-09-13 15:56 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805604&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) >Assigned to: Martin v. L?wis (loewis) Summary: fix --without-threads Initial Comment: Currently, Pyhton builds always against libpthread on systems that have sem_init in libpthread. Even if configure was invoked --without-threads. The patch changes this behaviour to only check for sem_init if python will be built with threads (with_threads = "yes or empty). Second, on systems that support a compiler switch for thread support (eg. -pthread) and have C++ support CXX will always set to CXX + flag, even in the unthreaded case. The patch fixes that. The patch is against release23-maint. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805604&group_id=5470 From noreply at sourceforge.net Thu Sep 18 17:11:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 18 17:11:50 2003 Subject: [Patches] [ python-Patches-805613 ] PTH related fixes Message-ID: Patches item #805613, was opened at 2003-09-13 16:15 Message generated for change (Comment added) made by marc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805613&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: PTH related fixes Initial Comment: Some PTH fixes with have in NetBSD's pkgsrc for a some time now. They're needed on NetBSD <= 1.6.x for Python + PTH to run properly. (And probably on other systems using PTH, too.) Basically the stack-size of PTH is way too small and _POSIX_THREADS shouldn't be defined. The patch is against release23-maint. Note: I'm not the original autor of this patch. I have permission to submit it, though. ---------------------------------------------------------------------- >Comment By: Marc Recht (marc) Date: 2003-09-18 23:11 Message: Logged In: YES user_id=205 NetBSD 1.6.x, the release/stable version comes without any thread support in the base systems. Therefore pth is used as primary threading library. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-18 20:51 Message: Logged In: YES user_id=21627 Is pth actively being used on that system? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805613&group_id=5470 From noreply at sourceforge.net Thu Sep 18 17:51:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 18 17:51:29 2003 Subject: [Patches] [ python-Patches-806800 ] NetBSD py_curses.h fix Message-ID: Patches item #806800, was opened at 2003-09-15 22:47 Message generated for change (Comment added) made by marc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=806800&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: NetBSD py_curses.h fix Initial Comment: On NetBSD, [n]curses.h and stdlib.h/wchar.h use different guards against multiple definition of wchar_t and wint_t. ---------------------------------------------------------------------- >Comment By: Marc Recht (marc) Date: 2003-09-18 23:51 Message: Logged In: YES user_id=205 Hmm. I won't consider it a bug in NetBSD. Just a clash of declarations.. ;-) The attached patch is needed for 1.6.x and -current (which will be released not sooner than next year). I'm not sure about 1.5, but I'd bet it's the same. So, there's just no restriction possible. It's simply - all - (if _XOPEN_SOURCE_EXTENDED is defined). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-18 20:33 Message: Logged In: YES user_id=21627 That is a work around a NetBSD bug, right? If so, there should be some procedure to retest presence of the bug in new NetBSD releases, and record the versions for which the bug has been found to be present. Then, when the newest release with the bug is not supported in Python anymore, the code can be removed (which might well be 10 years from now). If possible, a code fragment like #if (NetBSD_major == 3) or (NetBSD_major==4) // bug present, add work-around #else #error Please check whether the bug is still present #endif ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=806800&group_id=5470 From noreply at sourceforge.net Thu Sep 18 17:55:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 18 17:56:11 2003 Subject: [Patches] [ python-Patches-805626 ] make test_fcntl 64bit clean Message-ID: Patches item #805626, was opened at 2003-09-13 16:54 Message generated for change (Comment added) made by marc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805626&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: make test_fcntl 64bit clean Initial Comment: Patch to make test_fcntl.py 64bit clean (from NetBSD's pkgsrc) The patch is against release23-maint. Note: I'm not the original autor of this patch. I have permission to submit it, though. ---------------------------------------------------------------------- >Comment By: Marc Recht (marc) Date: 2003-09-18 23:55 Message: Logged In: YES user_id=205 To be honest, I'm not sure. It is tested on Alpha on NetBSD, though. And it is in "pkgsrc" for quite some time now and noone filed a PR. (But this could also mean that just nobody runs the tests..) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-18 20:48 Message: Logged In: YES user_id=21627 Does the patch work on all systems? For both byte orders? On both 32-bit and 64-bit systems? I'm particularly concerned about big-endian 32-bit systems, as the padding apparently is intended for little-endian systems only. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805626&group_id=5470 From noreply at sourceforge.net Thu Sep 18 18:45:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 18 18:45:38 2003 Subject: [Patches] [ python-Patches-806800 ] NetBSD py_curses.h fix Message-ID: Patches item #806800, was opened at 2003-09-15 22:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=806800&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: NetBSD py_curses.h fix Initial Comment: On NetBSD, [n]curses.h and stdlib.h/wchar.h use different guards against multiple definition of wchar_t and wint_t. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-19 00:45 Message: Logged In: YES user_id=21627 Is it the case that curses.h and wchar.h cannot be simultaneously be included if a certain supported #define is given? If so, it is clearly a bug in the header files - it should not be possible to get conflicting declarations by just including system headers. Even if it applies to all released versions of the system, I still need an explicit list of what these versions are, and I need a compile-time failure if a version is encountered that isn't listed. That the next release is only a year away is a good thing - maybe they can fix the bug until then. They won't, of course, fix the bug if nobody tells them there is a bug... ---------------------------------------------------------------------- Comment By: Marc Recht (marc) Date: 2003-09-18 23:51 Message: Logged In: YES user_id=205 Hmm. I won't consider it a bug in NetBSD. Just a clash of declarations.. ;-) The attached patch is needed for 1.6.x and -current (which will be released not sooner than next year). I'm not sure about 1.5, but I'd bet it's the same. So, there's just no restriction possible. It's simply - all - (if _XOPEN_SOURCE_EXTENDED is defined). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-18 20:33 Message: Logged In: YES user_id=21627 That is a work around a NetBSD bug, right? If so, there should be some procedure to retest presence of the bug in new NetBSD releases, and record the versions for which the bug has been found to be present. Then, when the newest release with the bug is not supported in Python anymore, the code can be removed (which might well be 10 years from now). If possible, a code fragment like #if (NetBSD_major == 3) or (NetBSD_major==4) // bug present, add work-around #else #error Please check whether the bug is still present #endif ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=806800&group_id=5470 From noreply at sourceforge.net Thu Sep 18 18:49:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 18 18:50:10 2003 Subject: [Patches] [ python-Patches-805626 ] make test_fcntl 64bit clean Message-ID: Patches item #805626, was opened at 2003-09-13 16:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805626&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: make test_fcntl 64bit clean Initial Comment: Patch to make test_fcntl.py 64bit clean (from NetBSD's pkgsrc) The patch is against release23-maint. Note: I'm not the original autor of this patch. I have permission to submit it, though. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-19 00:49 Message: Logged In: YES user_id=21627 The Alpha version likely runs fine because it is a 64-bit system, so they use all 8 bytes of the padding (even if in a different order then the original layout - I assume the structure definition is completely different from the one for 32-bit systems?) I'm mostly concerned about OS X, and perhaps other PPC systems, as well as 32-bit SPARC. It would be good if you could report the *BSD definitions of the structure on various architectures. ---------------------------------------------------------------------- Comment By: Marc Recht (marc) Date: 2003-09-18 23:55 Message: Logged In: YES user_id=205 To be honest, I'm not sure. It is tested on Alpha on NetBSD, though. And it is in "pkgsrc" for quite some time now and noone filed a PR. (But this could also mean that just nobody runs the tests..) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-18 20:48 Message: Logged In: YES user_id=21627 Does the patch work on all systems? For both byte orders? On both 32-bit and 64-bit systems? I'm particularly concerned about big-endian 32-bit systems, as the padding apparently is intended for little-endian systems only. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805626&group_id=5470 From noreply at sourceforge.net Thu Sep 18 21:03:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 18 21:03:48 2003 Subject: [Patches] [ python-Patches-762934 ] address test_time.py failures under Redhat 6.2 Message-ID: Patches item #762934, was opened at 2003-06-29 17:44 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762934&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Brett Cannon (bcannon) Summary: address test_time.py failures under Redhat 6.2 Initial Comment: A mangled version of this patch is also in bug: http://www.python.org/sf/728051 Looks like tzset(3) is broken under Redhat 6.2 in a way that wasn't being detected by configure. This patch adds stricter tzset(3) checking to configure.in. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-09-18 18:03 Message: Logged In: YES user_id=357491 Kurt's patch has been checked in both to HEAD and release23- maint. Thanks, Kurt, for all your hard work. ---------------------------------------------------------------------- Comment By: Jordan Krushen (furie) Date: 2003-09-17 10:51 Message: Logged In: YES user_id=218883 I've tested kbk's patch on fresh installs of both RH 6.1 and 6. 2, and they both pass all (non-skipped) tests. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-07 20:11 Message: Logged In: YES user_id=357491 OK, so Kurt's thinking and debugging all seem good to me. I applied the patch and it worked correctly for me. Can other people test it (not just Red Hat but also other platforms; OS X is covered by my test)? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-24 23:48 Message: Logged In: YES user_id=357491 Thanks for the debugging work, Kurt. I will take a good look at this when 2.4 dev starts. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-24 20:48 Message: Logged In: YES user_id=149084 [kbk@float ~/PYSRC]$ ./python Python 2.3c2 (#15, Jul 24 2003, 11:17:16) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> from os import environ >>> victoria = 'AEST-10AEDT-11,M10.5.0,M3.5.0' >>> environ['TZ'] = victoria >>> time.tzset() >>> time.tzname ('AEST', 'AEST') >>> ========================================= Hm!! Try a couple of things to try to see what's going on: ========================================= >>> victoria2 = 'AEST-10AEDT-11' >>> environ['TZ'] = victoria2 >>> time.tzset() >>> time.tzname ('AEST', 'AEDT') >>> >>> # try reversing the changeover ... >>> victoria3 = 'AEST-10AEDT-11,M3.5.0,M10.5.0' >>> environ['TZ'] = victoria3 >>> time.tzset() >>> time.tzname ('AEST', 'AEDT') =================================== ok, debug inittimezone: =================================== Breakpoint 1, inittimezone (m=0x4014053c) at /home/kbk/PYTHON/python/dist/src/Modules/timemodule.c:608 608t = (time((time_t *)0) / YEAR) * YEAR; (gdb) n 609p = localtime(&t); (gdb) p asctime(localtime(&t)) $14 = 0x4013be00 "Wed Jan 1 16:00:00 2003\n" (gdb) p localtime(&t)->tm_zone $19 = 0x8162b78 "AEST" [std time on Jan 1!! ...back up a day or so....] (gdb) p t = t - 84000 $20 = 1041316800 (gdb) p localtime(&t)->tm_zone $21 = 0x8162b90 "AEDT" (gdb) p asctime(localtime(&t)) $22 = 0x4013be00 "Tue Dec 31 17:40:00 2002\n" (gdb) =================================== so Linux6.2 thinks AEDT switches to AEST in Jan, and six months forward is still AEST. xmas2002 is AEDT so config test passes but timemodule uses Jan 1 and flubs when setting tzname. Need to do the config test later than xmas. ===================================== *** Apply Patch SF 762934 configure.in.patch.kbk ====================================== autoreconf && ./configure && make clean && make OPT=-g ====================================== extract from configure log: .... checking for broken nice()... yes checking for working tzset()... no checking for tv_nsec in struct stat... no checking whether mvwdelch is an expression... yes .... ====================================== [kbk@float ~/PYSRC]$ ./python Python 2.3c2 (#18, Jul 24 2003, 22:40:09) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from test import test_time >>> test_time.test_main() test_asctime (test.test_time.TimeTestCase) ... ok test_clock (test.test_time.TimeTestCase) ... ok test_conversions (test.test_time.TimeTestCase) ... ok test_data_attributes (test.test_time.TimeTestCase) ... ok test_sleep (test.test_time.TimeTestCase) ... ok test_strftime (test.test_time.TimeTestCase) ... ok test_strptime (test.test_time.TimeTestCase) ... ok test_tzset (test.test_time.TimeTestCase) ... ok ------------------------------------------------------------ Ran 8 tests in 2.523s OK >>> =================================== make test: =================================== .... .... test_zlib 227 tests OK. 28 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl test_curses test_email_codecs test_gl test_imgfile test_largefile test_linuxaudiodev test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound Those skips are all expected on linux2. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-22 16:04 Message: Logged In: YES user_id=357491 Well, it is looking like tzset_AEST is not working as a solution. Hopefully Neal's patch will do the trick. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-22 15:46 Message: Logged In: YES user_id=33168 See this mail for a possible fix. http://mail.python.org/pipermail/python-dev/2003-July/037116.html Stuart, is that correct? It fixes the problem on RedHat 6.2 and doesn't break on RedHat 9. The change is to define YEAR as 365 * 24 * 3600, instead of adding 6 hours. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-16 13:05 Message: Logged In: YES user_id=44345 Works for me (Mac OS X) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-12 19:27 Message: Logged In: YES user_id=357491 Quick update: I got autoreconf to work and it seems to work for me. I also tested the C code in isolation and had no problems. So I now I just need other people to apply the patch and say whether it works. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-12 16:01 Message: Logged In: YES user_id=357491 Well, it didn't work for two people for Red Hat 6.2 . Perhaps being more explicit for the test? To give that a shot, I am uploading a patch that tests explicitly for AEDT as the daylight-savings timezone. I snagged the code mostly from Modules/timemodule.c . Now this is untested so there could be syntax problems. I can't get a proper version of Autoconf to run on my system so I can run autoreconf. Hopefully this will deal with the problem. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-10 07:29 Message: Logged In: YES user_id=12800 This patch didn't break RH9. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-03 13:16 Message: Logged In: YES user_id=357491 We can say it should fail under Linux, but we can't specify Red Hat 6.2. I am keeping an eye on this patch for bug #763153, but I have to wait until the OP applies it and tests it. Looking at the patch, beyond not realizing that the X-mas time was GMT initially and the unneeded variable assignments, the patch looks fine to me (might want to comment that tzset does not return a value; rather non-standard) although I am no autoconf expert and I am assuming it just compiles this C code and any problems it just says it fails. Neal, what OS are you running? If it is non-OS X (sorry, that's what I am running as well) can you give the patch a try? ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-07-01 20:51 Message: Logged In: YES user_id=46639 This patch has only been tested under OS X. I'm confident that it won't break other platforms. I have no real way of proving that it addresses the problem it is supposed to solve, however, as I don't have access to a box that fails the tzset test in test_time.py. The only reported platform that this is failing on is at http://www.python.org/sf/728051, so we could just flag this test as expected to fail on that platform, if someone knows how to do that. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-01 20:03 Message: Logged In: YES user_id=33168 Stuart, what boxes did you test this on? How confident are you that this won't break some other platform? I'm asking to try to determine if this should go into 2.3final (we only have 1 release candidate before release) or if this should wait for 2.3.1. Thanks for all your work on tzset. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762934&group_id=5470 From noreply at sourceforge.net Fri Sep 19 18:11:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 19 18:11:27 2003 Subject: [Patches] [ python-Patches-809535 ] Mention behavior of seek() on text files Message-ID: Patches item #809535, was opened at 2003-09-19 17:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=809535&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Nobody/Anonymous (nobody) Summary: Mention behavior of seek() on text files Initial Comment: Document the fact that seek() on text files can lead to undefined results, rather than leaving the user to read ftell() docs to find out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=809535&group_id=5470 From noreply at sourceforge.net Sat Sep 20 06:48:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 06:48:33 2003 Subject: [Patches] [ python-Patches-805604 ] fix --without-threads Message-ID: Patches item #805604, was opened at 2003-09-13 15:56 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805604&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Martin v. L?wis (loewis) Summary: fix --without-threads Initial Comment: Currently, Pyhton builds always against libpthread on systems that have sem_init in libpthread. Even if configure was invoked --without-threads. The patch changes this behaviour to only check for sem_init if python will be built with threads (with_threads = "yes or empty). Second, on systems that support a compiler switch for thread support (eg. -pthread) and have C++ support CXX will always set to CXX + flag, even in the unthreaded case. The patch fixes that. The patch is against release23-maint. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-20 12:48 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as configure 1.422 configure.in 1.433 configure 1.416.4.4 configure.in 1.427.4.4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805604&group_id=5470 From noreply at sourceforge.net Sat Sep 20 06:51:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 06:51:27 2003 Subject: [Patches] [ python-Patches-805678 ] Fix linking with shared libpython Message-ID: Patches item #805678, was opened at 2003-09-13 18:53 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805678&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Martin v. L?wis (loewis) Summary: Fix linking with shared libpython Initial Comment: If Python is build with a shared lib python it installs a libpython2.3.so.1.0 ( $(INSTSONAME) ). If Python is not installed into a standard dir (eg. /usr), for example $HOME/python this library is not found by the linker. Meaning this fails: gcc -L$HOME/lib -o myprog -lpython2.3 This fails because there is no "libpython2.3.so". If Python is installed into standard dirs - on Linux - this is handled by "ldconfig", but not for non-standard dirs or other unixes where ldconfig doesn't create the .so link. The attached patch fixes this by creating the needed symlink at install time. Tested Linux and NetBSD. The patch is against release23-maint. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-20 12:51 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as Makefile.pre.in 1.138 and 1.136.6.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805678&group_id=5470 From noreply at sourceforge.net Sat Sep 20 06:53:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 06:53:36 2003 Subject: [Patches] [ python-Patches-805976 ] Tkconstants.py - listbox activestyle constants Message-ID: Patches item #805976, was opened at 2003-09-14 15:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805976&group_id=5470 Category: Tkinter Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Martin v. L?wis (loewis) Summary: Tkconstants.py - listbox activestyle constants Initial Comment: This patch adds 2 constants to Tkconstants.py which can be used to set a listbox's activestyle option (added in Tk8.4). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-20 12:53 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as Tkconstants.py 1.10. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805976&group_id=5470 From noreply at sourceforge.net Sat Sep 20 06:59:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 06:59:32 2003 Subject: [Patches] [ python-Patches-793559 ] clear SGMLParser.__starttag_text on reset() Message-ID: Patches item #793559, was opened at 2003-08-23 02:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793559&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Andrew Gaul (gaul) Assigned to: Martin v. L?wis (loewis) Summary: clear SGMLParser.__starttag_text on reset() Initial Comment: Fixes bug 709491. SGMLParser.__starttag_text is not set to None on reset(), making calls to get_starttag_text() return incorrect results. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-20 12:59 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as sgmllib.py 1.46, 1.45.8.1 NEWS 1.831.4.47 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793559&group_id=5470 From noreply at sourceforge.net Sat Sep 20 07:01:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 07:02:13 2003 Subject: [Patches] [ python-Patches-764217 ] Fix for tkFont.Font(name=...) Message-ID: Patches item #764217, was opened at 2003-07-01 23:14 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764217&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Martin v. L?wis (loewis) Summary: Fix for tkFont.Font(name=...) Initial Comment: tkFont.Font(name=xxx) crashes if a font by the specified name already exists. This is a problem for several reasons, the main one being that it makes life really tough if you want to creat a new tkFont.Font object for a given Tcl named font. This simple fix handles the problem. I've also included a new method __eq__ so that two tkFont.Font objects that point to the same Tcl named font compare as equal. I felt this is important because the fix makes it easier to have multiple such tkFont.Font objects. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-20 13:01 Message: Logged In: YES user_id=21627 reowen, are you willing to revise the patch in this direction? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-13 17:57 Message: Logged In: YES user_id=21627 While the bug might be worth fixing, I think the approach taken is wrong. With the patch, it will invoke "font names" for all new tkFont objects, which might be a significant overhead. To really preserve current behaviour, it should continue to 'font create', and fall back to 'font configure' in case of an exception. Actually, it is not clear what the right behaviour is in the first place. 'font configure' would change the settings of the existing font. If the name clash is by coincidence, it would be better to raise an exception instead of silently modifying the existing font. In the face of ambiguity, refuse the temptation to guess. So to really fix this, tkFont.forName (or tkFont.existing) should be provided. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-13 17:32 Message: Logged In: YES user_id=80475 The first part of the patch appears reasonable. For the second part, it's a bit late for an API change. Martin, is this bugfix okay for Py2.3? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764217&group_id=5470 From noreply at sourceforge.net Sat Sep 20 07:05:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 07:05:42 2003 Subject: [Patches] [ python-Patches-713645 ] freeze fails when extensions_win32.ini is missing Message-ID: Patches item #713645, was opened at 2003-04-02 03:17 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713645&group_id=5470 Category: Demos and tools Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: David Schnepper (dschnepper) Assigned to: Martin v. L?wis (loewis) Summary: freeze fails when extensions_win32.ini is missing Initial Comment: Incorrect variable referenced during print of warning message when extensions_win32.ini is missing. Test: import checkextensions_win32 reload(checkextensions_win32) # for testing import os os.rename("extensions_win32.ini", "tmp.ini") try: checkextensions_win32.checkextensions([], [], "any") print "PASS: checkextensions with missing extensions_win32.ini" finally: os.rename("tmp.ini", "extensions_win32.ini") ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-20 13:05 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as NEWS 1.831.4.48 checkextensions_win32.py 1.8, 1.7.14.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713645&group_id=5470 From noreply at sourceforge.net Sat Sep 20 07:07:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 07:07:21 2003 Subject: [Patches] [ python-Patches-809535 ] Mention behavior of seek() on text files Message-ID: Patches item #809535, was opened at 2003-09-20 00:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=809535&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Nobody/Anonymous (nobody) Summary: Mention behavior of seek() on text files Initial Comment: Document the fact that seek() on text files can lead to undefined results, rather than leaving the user to read ftell() docs to find out. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-20 13:07 Message: Logged In: YES user_id=21627 what do you mean with " :se of other offsets" ??? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=809535&group_id=5470 From noreply at sourceforge.net Sat Sep 20 07:10:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 07:10:20 2003 Subject: [Patches] [ python-Patches-808362 ] typo fix for unittest and timeit Message-ID: Patches item #808362, was opened at 2003-09-18 09:13 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=808362&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: typo fix for unittest and timeit Initial Comment: I've found two typos in the library docs. #1 [10.10.1 Command Line Interface] www.python.org/dev/doc/devel/lib/node396.html > the default timer functions measures wall clock time this should read > the default timer functions measure wall clock time The same line can be found in Lib/timeit.py, so this also needs to be fixed. #2 [5.3.7 TestResult Objects] www.python.org/dev/doc/devel/lib/testresult- objects.html > and mmay be extended ... this should read > and may be extended ... ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-20 13:10 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as libtimeit.tex 1.6 libunittest.tex 1.16 timeit.py 1.14 libtimeit.tex 1.4.10.2 libunittest.tex 1.14.8.2 timeit.py 1.13.8.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=808362&group_id=5470 From noreply at sourceforge.net Sat Sep 20 07:14:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 07:14:26 2003 Subject: [Patches] [ python-Patches-805613 ] PTH related fixes Message-ID: Patches item #805613, was opened at 2003-09-13 16:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805613&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: PTH related fixes Initial Comment: Some PTH fixes with have in NetBSD's pkgsrc for a some time now. They're needed on NetBSD <= 1.6.x for Python + PTH to run properly. (And probably on other systems using PTH, too.) Basically the stack-size of PTH is way too small and _POSIX_THREADS shouldn't be defined. The patch is against release23-maint. Note: I'm not the original autor of this patch. I have permission to submit it, though. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-20 13:14 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as thread.c 2.47 thread_pth.h 2.10 NEWS 1.831.4.49 thread.c 2.46.10.1 thread_pth.h 2.9.16.1 ---------------------------------------------------------------------- Comment By: Marc Recht (marc) Date: 2003-09-18 23:11 Message: Logged In: YES user_id=205 NetBSD 1.6.x, the release/stable version comes without any thread support in the base systems. Therefore pth is used as primary threading library. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-18 20:51 Message: Logged In: YES user_id=21627 Is pth actively being used on that system? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=805613&group_id=5470 From noreply at sourceforge.net Sat Sep 20 07:15:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 07:15:08 2003 Subject: [Patches] [ python-Patches-803998 ] [_ssl.c] SSL_write() called with -1 as size Message-ID: Patches item #803998, was opened at 2003-09-10 22:51 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=803998&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ilario Nardinocchi (illo) >Assigned to: Martin v. L?wis (loewis) Summary: [_ssl.c] SSL_write() called with -1 as size Initial Comment: In the inner do/while loop of PySSL_SSLwrite(), whenever a SSL_write() needs to be called again after a SSL_ERROR_WANT_{READ,WRITE} error, its "len" parameter is set to -1, leading to a segfault. I can't believe nobody ever noticed that :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=803998&group_id=5470 From noreply at sourceforge.net Sat Sep 20 07:15:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 07:15:38 2003 Subject: [Patches] [ python-Patches-800697 ] Add 'clear_history()' to 'readline' module Message-ID: Patches item #800697, was opened at 2003-09-04 22:54 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=800697&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Phillip J. Eby (pje) >Assigned to: Martin v. L?wis (loewis) Summary: Add 'clear_history()' to 'readline' module Initial Comment: This patch adds a 'clear_history()' function to the readline module if the linked-to GNU readline library supports it. (See recent discussion on Python-Dev.) The attached patches are: rl23.txt - patch to readline.c based on current Python CVS HEAD rl223.txt - patch to readline.c based on Python 2.2.3 source distribution rldoc.txt - patch to add docs to Doc/lib/libreadline.tex ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=800697&group_id=5470 From noreply at sourceforge.net Sat Sep 20 07:17:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 07:17:12 2003 Subject: [Patches] [ python-Patches-788404 ] ignore "b" and "t" mode modifiers in posix_popen Message-ID: Patches item #788404, was opened at 2003-08-14 00:53 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788404&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Gaul (gaul) >Assigned to: Martin v. L?wis (loewis) Summary: ignore "b" and "t" mode modifiers in posix_popen Initial Comment: Fixes bug 703198. This patch removes any "b" or "t" modifiers, which have meaning in Windows (binary and text modes, respectively), but not in POSIX. This allows users to write portable code between Windows and POSIX when working on binary data in pipes: os.popen(cmd, 'rb'). ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-09-01 14:13 Message: Logged In: YES user_id=139865 *puzzles over why patch is so backward* Yes, it modifies an immutable object - double plus ungood. Attached is a simpler patch which does the right thing. Sorry, I do not know what was going through my head at the time. My best guess was that I thought that mode was a safe, mutable copy of the immutable Python string and I wanted to allow modes like "br", which the MSDN docs actually say are invalid ('b' and 't' modifiers must be appended). Note that the behaviour of POSIX posix_popen in this patch differs from Windows posix_popen, as the latter allows treats "rw", "r+", and "rr" as "r". In all three cases, POSIX systems throw "OSError: [Errno 22] Invalid argument" at pipe creation. In the case of "rw", Windows systems throw "IOError: [Errno 9] Bad file descriptor" when the read-only pipe is first written to. Ideally, Windows posix_popen should be modified to the new POSIX behaviour to give earlier error reporting. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-31 18:42 Message: Logged In: YES user_id=21627 Maybe I'm mistaken: Does this patch really modify the string object that is being passed? This would not be good: strings are immutable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788404&group_id=5470 From noreply at sourceforge.net Sat Sep 20 07:21:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 07:21:09 2003 Subject: [Patches] [ python-Patches-730597 ] RTEMS does not have a popen Message-ID: Patches item #730597, was opened at 2003-05-01 06:50 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730597&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Chris Johns (cjohns) Assigned to: Nobody/Anonymous (nobody) Summary: RTEMS does not have a popen Initial Comment: RTEMS port of Python. RTEMS supports POSIX but does not have a popen. RTEMS is a realtime operating system and has a single address space and no MMU so no fork, vfork or popen. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-20 13:21 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as posixmodule.c 2.304. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730597&group_id=5470 From noreply at sourceforge.net Sat Sep 20 07:18:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 07:21:47 2003 Subject: [Patches] [ python-Patches-755677 ] 755617: better docs for os.chmod Message-ID: Patches item #755677, was opened at 2003-06-17 05:35 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755677&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christopher Blunck (blunck2) >Assigned to: Martin v. L?wis (loewis) Summary: 755617: better docs for os.chmod Initial Comment: As per the discussion thread on c.l.p and summarized by Matthew Shomphe ---------------------------------------------------------------------- Comment By: Christopher Blunck (blunck2) Date: 2003-06-23 15:12 Message: Logged In: YES user_id=531881 Sure- According to the discussion here: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=mailman.1055808030.15325.python-list%40python.org&rnum=1&prev=/groups%3Fq%3Dos.chmod%2Bgroup:comp.lang.python.*%26hl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.lang.python.*%26selm%3Dmailman.1055808030.15325.python-list%2540python.org%26rnum%3D1 there was confusion as the behavior of os.chmod() on non-Unix platforms. Discussion led to a recommendation for a documentation change, which was submitted as an attachment to the bug report located here: http://www.python.org/sf/755617 The submitter of the bug report didn't know how to submit a patch. I decided to capture the documentation, add it to the appropriate tex file, produce a patch, and submit it to sf. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-06-21 15:33 Message: Logged In: YES user_id=21627 Can you give the rationale for this change, for those of us that don't know which thread you are referring to? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755677&group_id=5470 From noreply at sourceforge.net Sat Sep 20 07:22:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 07:22:32 2003 Subject: [Patches] [ python-Patches-723364 ] terminal type option subnegotiation in telnetlib Message-ID: Patches item #723364, was opened at 2003-04-17 23:13 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723364&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Jon Willeke (willeke) >Assigned to: Martin v. L?wis (loewis) Summary: terminal type option subnegotiation in telnetlib Initial Comment: The attached patch makes it possible for an option negotiation callback to subnegotiate the terminal type option (per RFC 1091). The patch does the following: * defines the SB and SE commands (per RFC 854) * defines QUAL_IS and QUAL_SEND (adapted from ) * passes SB ... SE to callback in process_rawq() A simple callback would specify the terminal type as follows: * respond to IAC DO TTYPE with IAC WILL TTYPE * respond to IAC SB TTYPE QUAL_SEND IAC SE with IAC SB TTYPE QUAL_IS 'vt100' IAC SE ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723364&group_id=5470 From noreply at sourceforge.net Sat Sep 20 07:23:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 07:23:46 2003 Subject: [Patches] [ python-Patches-707167 ] fix bug #682813: dircache.listdir doesn't signal error Message-ID: Patches item #707167, was opened at 2003-03-20 23:13 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=707167&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) >Assigned to: Martin v. L?wis (loewis) Summary: fix bug #682813: dircache.listdir doesn't signal error Initial Comment: Attached small patch makes dircache.listdir raise OSError when encountered in os.stat or os.listdir. This certainly seems like the right thing to do to be consistent with os.listdir, though there may have been a reason not to raise the exception I don't know about, as it is obviously being purposefully caught right now. If there is a reason, someone let me know and I'll submit a patch to change dircache's documentation to reflect its behavior. The test case is also updated by the patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-03-21 03:03 Message: Logged In: YES user_id=357491 Patch looks good. Don't let the wording in the description mislead you, though. No exception is specifically raised; it just is not caught anymore. As for whether this patch should be applied or not I have no clue since I never use the module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=707167&group_id=5470 From noreply at sourceforge.net Sat Sep 20 07:25:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 07:25:21 2003 Subject: [Patches] [ python-Patches-531629 ] Add multicall support to xmlrpclib Message-ID: Patches item #531629, was opened at 2002-03-19 00:00 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=531629&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) >Assigned to: Martin v. L?wis (loewis) Summary: Add multicall support to xmlrpclib Initial Comment: Adds a new object to xmlrpclib that allows the user to boxcared XML-RPC requests e.g. server_proxy = ServerProxy(...) multicall = MultiCall(server_proxy) multicall.add(2,3) multicall.get_address("Guido") add_result, address = multicall() see http://www.xmlrpc.com/discuss/msgReader$1208 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=531629&group_id=5470 From noreply at sourceforge.net Sat Sep 20 07:26:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 07:26:29 2003 Subject: [Patches] [ python-Patches-463656 ] setup.py, --with-includepath, and LD_LIB Message-ID: Patches item #463656, was opened at 2001-09-21 21:12 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=463656&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frederic Giacometti (giacometti) >Assigned to: Martin v. L?wis (loewis) Summary: setup.py, --with-includepath, and LD_LIB Initial Comment: This patch improves the module detection capability in setup.py. The following improvements are implemented: - directories listed in LD_LIBRARY_PATH are also searched for shared libraries. - the --with-includepath option has been added to configure, to specify additional non-standard directories where the include files are to be searched for. The corresponding changes were added to setup.py (new function detect_include(), find_library_file() augmented, detect_tkinter() improved) I retroceeded manually the changes from configure into configure.in, but I did not run autoconf; you might want to double-check this. Sample aplication: ./configure --prefix=/something --with-includepath='/mgl/apps/include:/mgl/share/include' With this patch, I get Tkinter to build correctly without editing the Setup files, with non-standard tckl/tk 8.0 to 8.3 installations. where the only tcl.h file is in /mgl/share/include/tcl8.0 (therefore, tkinter is build with tcl8.0 on this configuration). FG ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-09 02:30 Message: Logged In: YES user_id=357491 Is that last response a "yes" or a "no"? =) Any of the distutils guys think we should apply this patch or can we finally close this (it was opened over a 1.5 years ago)? ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2002-08-17 21:24 Message: Logged In: YES user_id=93657 On one hand, using -I and -L from setup.py would simplify the setup.py code, but on the other hand, in the present build system, this will require coding in configure.in some of what we can write in python in setup.py (e.g. the use of LD_SHARED_LIBRARY by default). I know we get the eternal story (I already hear it every day with Perl, awk, and various forms of platform-dependent shell scripting), that autoconf is a great and well-known programming language which everybody uses, and why should we do in Python what we can already do in autoconf, and so on... I wish I could put a smiley on this, but I stopped laughing at this things, since I meet them endlessly. Regards, FG ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-08-14 16:56 Message: Logged In: YES user_id=21627 Frederic, do you still think there is a need for this patch? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-17 18:58 Message: Logged In: YES user_id=6656 You do know that you can pass -I and -L options to setup.py? That might be a less involved way of doing what you want. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-28 02:17 Message: Logged In: YES user_id=93657 I moved the functions find_library_file() and detect_include() to distutils.sysconfig(), so that they can be reused for configuring third party modules too (e.g.: PyOpenGL...). Let me know if you wish a patch for this. Frederic Giacometti ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-27 00:56 Message: Logged In: YES user_id=93657 I'm replacing the patch with an improved version (against main line as of 09/26/01). New features: - configure is generated from configure.in, with autoconf - detect_tkinter also checks the version number inside the tcl.h and tk.h files (#define TCL_VERSION, #define TK_VERSION...). The 'tk_detect' improvement is in this same patch as the '--include-patch' feature; since the second one was written to get the first one working. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=463656&group_id=5470 From noreply at sourceforge.net Sat Sep 20 07:40:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 07:40:59 2003 Subject: [Patches] [ python-Patches-510695 ] cycle profiler for VM opcodes Message-ID: Patches item #510695, was opened at 2002-01-30 14:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=510695&group_id=5470 Category: Core (C code) Group: None Status: Open >Resolution: Accepted Priority: 1 Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: cycle profiler for VM opcodes Initial Comment: This is just some code I'm noodling around with. It counts the number of cycles each Python VM opcode takes to execute, using the Pentium timestamp counter. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-20 13:40 Message: Logged In: YES user_id=21627 OTOH, the patch is prepared for temporary usage, by means of a configure option. Since nobody has been objecting strongly, I'll accept this patch. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-11-12 14:26 Message: Logged In: YES user_id=4771 I think that you should try and convince people that it is a generally useful information to have, and that the fact that it is highly non-portable does not hurt. Right now it looks more like a change that a core developer would temporarily want to do to tune the VM. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-09 17:16 Message: Logged In: YES user_id=31392 sure ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-07 23:12 Message: Logged In: YES user_id=21627 Is this still of relevance? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=510695&group_id=5470 From noreply at sourceforge.net Sat Sep 20 10:55:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 10:55:58 2003 Subject: [Patches] [ python-Patches-809535 ] Mention behavior of seek() on text files Message-ID: Patches item #809535, was opened at 2003-09-19 17:11 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=809535&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Nobody/Anonymous (nobody) Summary: Mention behavior of seek() on text files Initial Comment: Document the fact that seek() on text files can lead to undefined results, rather than leaving the user to read ftell() docs to find out. ---------------------------------------------------------------------- >Comment By: Jeff Epler (jepler) Date: 2003-09-20 09:55 Message: Logged In: YES user_id=2772 ":se of other offsets" should have read "Use of other offsets". Or else it should match the libstdtypes.tex wording, "Other offsets cause undefined behavior." The patch I'm attaching now says "Use of other offets causes", and copies the docstring warning "not all file objects are seekable" into the tex documentation. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-20 06:07 Message: Logged In: YES user_id=21627 what do you mean with " :se of other offsets" ??? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=809535&group_id=5470 From noreply at sourceforge.net Sat Sep 20 11:10:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 11:10:43 2003 Subject: [Patches] [ python-Patches-807334 ] Prevent duplicate warnings filters Message-ID: Patches item #807334, was opened at 2003-09-16 14:13 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=807334&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Jeremy Hylton (jhylton) Summary: Prevent duplicate warnings filters Initial Comment: Multiple registration of the same filter contributes no value but causes unnecessary growing reference counts for repeated tests. Also, the duplicates slow down the already excrutiatingly slow warning.warn() which now appears throughout the codebase. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=807334&group_id=5470 From noreply at sourceforge.net Sat Sep 20 11:46:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 11:46:19 2003 Subject: [Patches] [ python-Patches-463656 ] setup.py, --with-includepath, and LD_LIB Message-ID: Patches item #463656, was opened at 2001-09-21 21:12 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=463656&group_id=5470 Category: Distutils and setup.py Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Frederic Giacometti (giacometti) Assigned to: Martin v. L?wis (loewis) Summary: setup.py, --with-includepath, and LD_LIB Initial Comment: This patch improves the module detection capability in setup.py. The following improvements are implemented: - directories listed in LD_LIBRARY_PATH are also searched for shared libraries. - the --with-includepath option has been added to configure, to specify additional non-standard directories where the include files are to be searched for. The corresponding changes were added to setup.py (new function detect_include(), find_library_file() augmented, detect_tkinter() improved) I retroceeded manually the changes from configure into configure.in, but I did not run autoconf; you might want to double-check this. Sample aplication: ./configure --prefix=/something --with-includepath='/mgl/apps/include:/mgl/share/include' With this patch, I get Tkinter to build correctly without editing the Setup files, with non-standard tckl/tk 8.0 to 8.3 installations. where the only tcl.h file is in /mgl/share/include/tcl8.0 (therefore, tkinter is build with tcl8.0 on this configuration). FG ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-20 17:46 Message: Logged In: YES user_id=21627 Ok, I'm rejecting the patch. It is outdated, and it is also partially wrong: LD_LIBRARY_PATH should not be used to determine directories which the static linker should look in; using LD_RUN_PATH for that might be a better choice. With LD_LIBRARY_PATH, the administrator would get an installation which might not work for his users, and he might not even know why it fails for users when it works for him. If additional directories are searched, the administrator needs to request them in a more explicit way. Frederic, if you are still interested in such a feature, please submit a patch against 2.3 or current CVS, and I promise to review it in a more timely manner. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-09 02:30 Message: Logged In: YES user_id=357491 Is that last response a "yes" or a "no"? =) Any of the distutils guys think we should apply this patch or can we finally close this (it was opened over a 1.5 years ago)? ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2002-08-17 21:24 Message: Logged In: YES user_id=93657 On one hand, using -I and -L from setup.py would simplify the setup.py code, but on the other hand, in the present build system, this will require coding in configure.in some of what we can write in python in setup.py (e.g. the use of LD_SHARED_LIBRARY by default). I know we get the eternal story (I already hear it every day with Perl, awk, and various forms of platform-dependent shell scripting), that autoconf is a great and well-known programming language which everybody uses, and why should we do in Python what we can already do in autoconf, and so on... I wish I could put a smiley on this, but I stopped laughing at this things, since I meet them endlessly. Regards, FG ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-08-14 16:56 Message: Logged In: YES user_id=21627 Frederic, do you still think there is a need for this patch? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-17 18:58 Message: Logged In: YES user_id=6656 You do know that you can pass -I and -L options to setup.py? That might be a less involved way of doing what you want. ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-28 02:17 Message: Logged In: YES user_id=93657 I moved the functions find_library_file() and detect_include() to distutils.sysconfig(), so that they can be reused for configuring third party modules too (e.g.: PyOpenGL...). Let me know if you wish a patch for this. Frederic Giacometti ---------------------------------------------------------------------- Comment By: Frederic Giacometti (giacometti) Date: 2001-09-27 00:56 Message: Logged In: YES user_id=93657 I'm replacing the patch with an improved version (against main line as of 09/26/01). New features: - configure is generated from configure.in, with autoconf - detect_tkinter also checks the version number inside the tcl.h and tk.h files (#define TCL_VERSION, #define TK_VERSION...). The 'tk_detect' improvement is in this same patch as the '--include-patch' feature; since the second one was written to get the first one working. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=463656&group_id=5470 From noreply at sourceforge.net Sat Sep 20 11:54:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 11:54:20 2003 Subject: [Patches] [ python-Patches-707167 ] fix bug #682813: dircache.listdir doesn't signal error Message-ID: Patches item #707167, was opened at 2003-03-20 23:13 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=707167&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Martin v. L?wis (loewis) Summary: fix bug #682813: dircache.listdir doesn't signal error Initial Comment: Attached small patch makes dircache.listdir raise OSError when encountered in os.stat or os.listdir. This certainly seems like the right thing to do to be consistent with os.listdir, though there may have been a reason not to raise the exception I don't know about, as it is obviously being purposefully caught right now. If there is a reason, someone let me know and I'll submit a patch to change dircache's documentation to reflect its behavior. The test case is also updated by the patch. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-20 17:54 Message: Logged In: YES user_id=21627 Thanks for the patch; I have committed it as whatsnew24.tex 1.3 dircache.py 1.12 test_dircache.py 1.6 NEWS 1.857 I will not backport it to 2.3 or earlier, because that is a behaviour change. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-03-21 03:03 Message: Logged In: YES user_id=357491 Patch looks good. Don't let the wording in the description mislead you, though. No exception is specifically raised; it just is not caught anymore. As for whether this patch should be applied or not I have no clue since I never use the module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=707167&group_id=5470 From noreply at sourceforge.net Sat Sep 20 12:04:37 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 12:07:53 2003 Subject: [Patches] [ python-Patches-755677 ] 755617: better docs for os.chmod Message-ID: Patches item #755677, was opened at 2003-06-17 05:35 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755677&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christopher Blunck (blunck2) Assigned to: Martin v. L?wis (loewis) Summary: 755617: better docs for os.chmod Initial Comment: As per the discussion thread on c.l.p and summarized by Matthew Shomphe ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-20 18:04 Message: Logged In: YES user_id=21627 I don't think that patch fixes the bug - IMO, the description of mode gets worse, not better, with this patch: 1. The mode is *not* a "four-digit number". It is a plain integer instead. Some people find it convenient to write this number in base8, using Python's octal number notation. 2. Other people find it convenient to use a symbolic bit mask to compute the number. Your patch removes the listing of the possible symbolic constants, which is bad. 3. You fail to mention some of the bits (e.g. the s-bits) which are available in the current documentation. 4. The patch fails to address the platform differences which atleast logistix considers important, in his comment to #755617 ---------------------------------------------------------------------- Comment By: Christopher Blunck (blunck2) Date: 2003-06-23 15:12 Message: Logged In: YES user_id=531881 Sure- According to the discussion here: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=mailman.1055808030.15325.python-list%40python.org&rnum=1&prev=/groups%3Fq%3Dos.chmod%2Bgroup:comp.lang.python.*%26hl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.lang.python.*%26selm%3Dmailman.1055808030.15325.python-list%2540python.org%26rnum%3D1 there was confusion as the behavior of os.chmod() on non-Unix platforms. Discussion led to a recommendation for a documentation change, which was submitted as an attachment to the bug report located here: http://www.python.org/sf/755617 The submitter of the bug report didn't know how to submit a patch. I decided to capture the documentation, add it to the appropriate tex file, produce a patch, and submit it to sf. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-06-21 15:33 Message: Logged In: YES user_id=21627 Can you give the rationale for this change, for those of us that don't know which thread you are referring to? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755677&group_id=5470 From noreply at sourceforge.net Sat Sep 20 12:09:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 12:09:19 2003 Subject: [Patches] [ python-Patches-800697 ] Add 'clear_history()' to 'readline' module Message-ID: Patches item #800697, was opened at 2003-09-04 22:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=800697&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Phillip J. Eby (pje) Assigned to: Martin v. L?wis (loewis) Summary: Add 'clear_history()' to 'readline' module Initial Comment: This patch adds a 'clear_history()' function to the readline module if the linked-to GNU readline library supports it. (See recent discussion on Python-Dev.) The attached patches are: rl23.txt - patch to readline.c based on current Python CVS HEAD rl223.txt - patch to readline.c based on Python 2.2.3 source distribution rldoc.txt - patch to add docs to Doc/lib/libreadline.tex ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-20 18:09 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as libreadline.tex 1.11 NEWS 1.858 readline.c 2.65 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=800697&group_id=5470 From noreply at sourceforge.net Sat Sep 20 12:11:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 12:11:27 2003 Subject: [Patches] [ python-Patches-809535 ] Mention behavior of seek() on text files Message-ID: Patches item #809535, was opened at 2003-09-20 00:11 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=809535&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) >Assigned to: Martin v. L?wis (loewis) Summary: Mention behavior of seek() on text files Initial Comment: Document the fact that seek() on text files can lead to undefined results, rather than leaving the user to read ftell() docs to find out. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2003-09-20 16:55 Message: Logged In: YES user_id=2772 ":se of other offsets" should have read "Use of other offsets". Or else it should match the libstdtypes.tex wording, "Other offsets cause undefined behavior." The patch I'm attaching now says "Use of other offets causes", and copies the docstring warning "not all file objects are seekable" into the tex documentation. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-20 13:07 Message: Logged In: YES user_id=21627 what do you mean with " :se of other offsets" ??? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=809535&group_id=5470 From noreply at sourceforge.net Sat Sep 20 15:52:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 15:52:21 2003 Subject: [Patches] [ python-Patches-809887 ] Improve pdb breakpoint feedback Message-ID: Patches item #809887, was opened at 2003-09-20 13:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=809887&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kevin J. Butler (kevinbutler) Assigned to: Nobody/Anonymous (nobody) Summary: Improve pdb breakpoint feedback Initial Comment: pdb was inconsistent in reporting changes to breakpoints, reporting 'Deleted breakpoint #' in one case, and not reporting the deletion in another. This patch makes pdb consistently report "Deleted/disabled/enabled breakpoint # at PATH:#" for deleting, enabling, or disabling a breakpoint. This makes it easier to integrate with IDEs such as emacs gud mode (see discussion on python-dev startig with http://mail.python.org/pipermail/python-dev/2003-September/038147.html ). Potential items for concern: - I completely replaced the Bdb.get_break method. It was returning a boolean indicating if the breakpoint existed or not, which appeared to be an error (get_breaks returned the list of breakpoints). The method was never used in bdb.py or pdb.py, so I replaced it with what I thought it should be. :-) That is, it now returns the breakpoint instance requested. If there is a reason, I can easily make this a new method (get_breakpoint/get_breakpointinstance) rather than replacing get_break. - I've duplicated logic from Bdb.clear_bpbynumber into a new method get_bpbynumber. The logic differs only in the return error messages or None. This seemed the simplest way to preserve the return value semantics convention of the Bdb class. - I'm also calling 'get', then 'clear' which does the work of 'get' twice. I did this to preserve the return value conventions of Bdb and make the breakpoint info available to the UI. Shouldn't be a performance issue, right? ;-) I believe this could go into 2.3.* and 2.4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=809887&group_id=5470 From noreply at sourceforge.net Sat Sep 20 17:25:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 17:25:04 2003 Subject: [Patches] [ python-Patches-809915 ] Fix bogus address to hopefully always break Message-ID: Patches item #809915, was opened at 2003-09-20 16:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=809915&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: J. Lewis Muir (jlmuir) Assigned to: Nobody/Anonymous (nobody) Summary: Fix bogus address to hopefully always break Initial Comment: VeriSign's new Site Finder service breaks the test_urllibnet.urlopenNetworkTests.test_bad_address test. Since the bogus test address is in the ".com" TLD, even though it is a nonexistent second-level domain name, it gets resolved to VeriSign's Site Finder web page and so the expected IOError is not raised. I changed the intentionally bogus address, "www.sadflkjsasadf.com", to "www.python.invalid" in the hopes that this will always be invalid. The ".invalid" TLD is reserved for such a purpose according to RFC 2606, "Reserved Top Level DNS Names". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=809915&group_id=5470 From noreply at sourceforge.net Sat Sep 20 18:17:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 20 18:17:50 2003 Subject: [Patches] [ python-Patches-809915 ] Fix bogus address to hopefully always break Message-ID: Patches item #809915, was opened at 2003-09-20 17:25 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=809915&group_id=5470 Category: Tests Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: J. Lewis Muir (jlmuir) Assigned to: Nobody/Anonymous (nobody) Summary: Fix bogus address to hopefully always break Initial Comment: VeriSign's new Site Finder service breaks the test_urllibnet.urlopenNetworkTests.test_bad_address test. Since the bogus test address is in the ".com" TLD, even though it is a nonexistent second-level domain name, it gets resolved to VeriSign's Site Finder web page and so the expected IOError is not raised. I changed the intentionally bogus address, "www.sadflkjsasadf.com", to "www.python.invalid" in the hopes that this will always be invalid. The ".invalid" TLD is reserved for such a purpose according to RFC 2606, "Reserved Top Level DNS Names". ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-09-20 18:17 Message: Logged In: YES user_id=31435 Grrrrrr (to VeriSign), and thanks. The suggested change has been checked in, Lib/test/test_urllibnet.py; new revision: 1.7 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=809915&group_id=5470 From noreply at sourceforge.net Sun Sep 21 01:13:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 21 01:13:50 2003 Subject: [Patches] [ python-Patches-810023 ] Fix for off-by-one bug in urllib.URLopener.retrieve Message-ID: Patches item #810023, was opened at 2003-09-21 00:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810023&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: J. Lewis Muir (jlmuir) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for off-by-one bug in urllib.URLopener.retrieve Initial Comment: This patch fixes an off-by-one bug in the reporthook part of urllib.URLopener.retrieve and adds test cases to verify the fix. The retrieve method reports reading one more block than it actually does. Here's an example. The file is empty. I expect the initial reporthook call on establishment of the network connection but not an additional call since the file is empty (no block was read): >>> import urllib >>> def reporter(count, blockSize, fileSize): ... print "c: %i, bs: %i, fs: %i" % (count, blockSize, fileSize) ... >>> srcFile = file("/tmp/empty.txt", "wb") >>> srcFile.close() >>> urllib.urlretrieve("file:///tmp/empty.txt", "/tmp/new- empty.txt", reporter) c: 0, bs: 8192, fs: 0 c: 1, bs: 8192, fs: 0 ('/tmp/new-empty.txt', ) >>> As a second example, if the file contains 1 byte, the retrieve method claims it read 2 blocks when it really only read 1: >>> srcFile = file("/tmp/empty.txt", "wb") >>> srcFile.write("x") >>> srcFile.close() >>> urllib.urlretrieve("file:///tmp/empty.txt", "/tmp/new- empty.txt", reporter) c: 0, bs: 8192, fs: 1 c: 1, bs: 8192, fs: 1 c: 2, bs: 8192, fs: 1 ('/tmp/new-empty.txt', ) >>> This patch also includes some changes to test_urllib.urlretrieve_FileTests (where I added the test cases) to support creating more than one temporary file and making sure any created temporary files get deleted when the test case fixture is torn down. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810023&group_id=5470 From noreply at sourceforge.net Sun Sep 21 15:32:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 21 15:32:45 2003 Subject: [Patches] [ python-Patches-810242 ] Typos (words repeated twice, etc.) Message-ID: Patches item #810242, was opened at 2003-09-21 19:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810242&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sergey Svishchev (shattered) Assigned to: Nobody/Anonymous (nobody) Summary: Typos (words repeated twice, etc.) Initial Comment: A Perl one-liner from FMTEYEWTK found a number of sentences where one word is repeated twice in a row. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810242&group_id=5470 From noreply at sourceforge.net Mon Sep 22 09:10:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 22 09:10:56 2003 Subject: [Patches] [ python-Patches-801847 ] Adding rsplit() to string and unicode objects. Message-ID: Patches item #801847, was opened at 2003-09-06 20:52 Message generated for change (Comment added) made by jemfinch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=801847&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Guido van Rossum (gvanrossum) Summary: Adding rsplit() to string and unicode objects. Initial Comment: I'm attaching patches to the library and documentation for implementing rsplit() on string and unicode objects. This works like split(), but working from the right. ./python -c 'print u"foo, bar, baz".rsplit(None, 1)' [u'foo, bar,', u'baz'] This was supposed to be against the CVS code, but I've had a heck of a time getting it checked out -- my checkout has been hung for half an hour now. The code patch is against the 2.3 release, the docs patch is against the CVS. My checkout got to docs, but I didn't have the code to a point where I could build and test it. Sean ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-09-22 09:10 Message: Logged In: YES user_id=99508 As a comment on the ease with which a programmer can get rsplit wrong, note that rhettinger's rsplit implementation is not correct: compare rsplit('foobarbaz', 'bar') with 'foobarbaz'.split('bar'). He forgot to reverse the separator if it's not None. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-11 19:55 Message: Logged In: YES user_id=80475 Guido, do you care to pronounce on this one? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-11 02:07 Message: Logged In: YES user_id=21627 There is PEP 2, which suggests to write a library PEP for proposal to extend the library. Now, this probably would be overkill for a single string method. However, I feel that there are already too many string methods, so I won't accept that patch. I'm not rejecting it, either, because I see that other maintainers might have a different opinion. In short, you should propose your change to python-dev, finding out what "a majority" of the maintainers thinks; you might also propose it on python-list, trying to collect reactions from users. It would then be good to summarize these discussions here (instead of carrying them out here). ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-10 16:40 Message: Logged In: YES user_id=81797 I realize that rsplit() can be implemented, because, well, I implemented it. The standard library is there to provide ready-to-use functionality so that users of python can concentrate on their program instead of concentrate on re-inventing the wheel. find() can be implemented with a short loop, split() can be implemented with find(), join() can be implemented with a short loop. Many things can be implemented with a little additional effort on the part of the user to develop or locate the code they're wanting. These little things can add up quickly and can have quite a dramatic impact on the programming experience in Python. Having to find or implement these functions will cause distraction from the code at hand, time lost while finding, implementing, testing, and maintaining the code in question. One of Python's strengths is a rich standard library. So, what are the guidelines for determining when it's rich enough? Why is it ok to suggest that users should get distracted from their code to go implement something else? Is there a policy that I'm not aware of that new functionality should be put in the cookbook instead of the standard library? Why is it being ignored that some programmers would find implementing rsplit() challenging? I'm not trying to be difficult here, I honestly can't understand the apparent change from having a rich library to a "batteries not included" stance. The response I got from #python when I mentioned having submitted the patch indicates to me that other experienced Python developers expect there to be an rsplit(). So, why is there so much resistance to adding something to the library? What are the guidelines for determining if something should be in the library? Sean ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-10 15:35 Message: Logged In: YES user_id=80475 I would classify this more as a technique than a fundamental string operation implemented by all stringlike objects (including UserString). Accordingly, I recommend that the patch be closed and a recipe posted in the ASPN cookbook - something along the lines of: >>> def rsplit(s, sep=None, maxsplit=-1): ... return [chunk[::-1] for chunk in s[::-1].split(sep, maxsplit)[::-1]] >>> rsplit(u"foo, bar, baz", None, 1) [u'foo, bar,', u'baz'] ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-10 15:15 Message: Logged In: YES user_id=81797 os.path.basename/os.path.dirname is an example of where you could use rsplit. One of the other #python folks said he had recently wanted rsplit for an application where he was getting the domain name and user part from a list of e-mail addresses, but found that some entries contained an "@" in the user part. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-10 13:08 Message: Logged In: YES user_id=21627 I questioned the usefulness because I could not think of a meaningful application. Now I see what a potential application could be, but I doubt its generality, because that approach would break if there could be two fields that have commas in them. I also disagree that symmetry can motivate usefulness: I also doubt that all of the r* functions are useful, but they cannot be removed for backwards compatibility. The fact that rsplit would fit together with the other r* functions indicates that adding rsplit would provide symmetry, not that it would provide usefulness. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-07 20:56 Message: Logged In: YES user_id=81797 Can you provide more details about why the usefulness of this function is in question? First I would like to tell you the story of it coming to be, then I will answer your incomplete question with a (probably) incomplete answer. I had a device which sent me comma-separated fields, but one of the fields in the middle could contain a comma. The answer that seemed obvious to me was to use split with a maxsplit to get the fields up to that field, and then a rsplit with a maxsplit on the remainder. When I mentioned on #python that I was implementing rsplit, 4 other fellow python users replied right away that they had been wanting it. To answer your question, it's useful because people using strings are used to having r*() functions like rfind and rstrip. The lack of rsplit is kind of glaring in this context. Really, though, it's useful because otherwise people have to implement -- often badly. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-07 15:49 Message: Logged In: YES user_id=21627 Why is this function useful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=801847&group_id=5470 From noreply at sourceforge.net Mon Sep 22 10:32:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 22 10:33:07 2003 Subject: [Patches] [ python-Patches-801847 ] Adding rsplit() to string and unicode objects. Message-ID: Patches item #801847, was opened at 2003-09-06 19:52 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=801847&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) >Assigned to: Raymond Hettinger (rhettinger) Summary: Adding rsplit() to string and unicode objects. Initial Comment: I'm attaching patches to the library and documentation for implementing rsplit() on string and unicode objects. This works like split(), but working from the right. ./python -c 'print u"foo, bar, baz".rsplit(None, 1)' [u'foo, bar,', u'baz'] This was supposed to be against the CVS code, but I've had a heck of a time getting it checked out -- my checkout has been hung for half an hour now. The code patch is against the 2.3 release, the docs patch is against the CVS. My checkout got to docs, but I didn't have the code to a point where I could build and test it. Sean ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-09-22 08:10 Message: Logged In: YES user_id=99508 As a comment on the ease with which a programmer can get rsplit wrong, note that rhettinger's rsplit implementation is not correct: compare rsplit('foobarbaz', 'bar') with 'foobarbaz'.split('bar'). He forgot to reverse the separator if it's not None. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-11 18:55 Message: Logged In: YES user_id=80475 Guido, do you care to pronounce on this one? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-11 01:07 Message: Logged In: YES user_id=21627 There is PEP 2, which suggests to write a library PEP for proposal to extend the library. Now, this probably would be overkill for a single string method. However, I feel that there are already too many string methods, so I won't accept that patch. I'm not rejecting it, either, because I see that other maintainers might have a different opinion. In short, you should propose your change to python-dev, finding out what "a majority" of the maintainers thinks; you might also propose it on python-list, trying to collect reactions from users. It would then be good to summarize these discussions here (instead of carrying them out here). ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-10 15:40 Message: Logged In: YES user_id=81797 I realize that rsplit() can be implemented, because, well, I implemented it. The standard library is there to provide ready-to-use functionality so that users of python can concentrate on their program instead of concentrate on re-inventing the wheel. find() can be implemented with a short loop, split() can be implemented with find(), join() can be implemented with a short loop. Many things can be implemented with a little additional effort on the part of the user to develop or locate the code they're wanting. These little things can add up quickly and can have quite a dramatic impact on the programming experience in Python. Having to find or implement these functions will cause distraction from the code at hand, time lost while finding, implementing, testing, and maintaining the code in question. One of Python's strengths is a rich standard library. So, what are the guidelines for determining when it's rich enough? Why is it ok to suggest that users should get distracted from their code to go implement something else? Is there a policy that I'm not aware of that new functionality should be put in the cookbook instead of the standard library? Why is it being ignored that some programmers would find implementing rsplit() challenging? I'm not trying to be difficult here, I honestly can't understand the apparent change from having a rich library to a "batteries not included" stance. The response I got from #python when I mentioned having submitted the patch indicates to me that other experienced Python developers expect there to be an rsplit(). So, why is there so much resistance to adding something to the library? What are the guidelines for determining if something should be in the library? Sean ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-10 14:35 Message: Logged In: YES user_id=80475 I would classify this more as a technique than a fundamental string operation implemented by all stringlike objects (including UserString). Accordingly, I recommend that the patch be closed and a recipe posted in the ASPN cookbook - something along the lines of: >>> def rsplit(s, sep=None, maxsplit=-1): ... return [chunk[::-1] for chunk in s[::-1].split(sep, maxsplit)[::-1]] >>> rsplit(u"foo, bar, baz", None, 1) [u'foo, bar,', u'baz'] ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-10 14:15 Message: Logged In: YES user_id=81797 os.path.basename/os.path.dirname is an example of where you could use rsplit. One of the other #python folks said he had recently wanted rsplit for an application where he was getting the domain name and user part from a list of e-mail addresses, but found that some entries contained an "@" in the user part. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-10 12:08 Message: Logged In: YES user_id=21627 I questioned the usefulness because I could not think of a meaningful application. Now I see what a potential application could be, but I doubt its generality, because that approach would break if there could be two fields that have commas in them. I also disagree that symmetry can motivate usefulness: I also doubt that all of the r* functions are useful, but they cannot be removed for backwards compatibility. The fact that rsplit would fit together with the other r* functions indicates that adding rsplit would provide symmetry, not that it would provide usefulness. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-07 19:56 Message: Logged In: YES user_id=81797 Can you provide more details about why the usefulness of this function is in question? First I would like to tell you the story of it coming to be, then I will answer your incomplete question with a (probably) incomplete answer. I had a device which sent me comma-separated fields, but one of the fields in the middle could contain a comma. The answer that seemed obvious to me was to use split with a maxsplit to get the fields up to that field, and then a rsplit with a maxsplit on the remainder. When I mentioned on #python that I was implementing rsplit, 4 other fellow python users replied right away that they had been wanting it. To answer your question, it's useful because people using strings are used to having r*() functions like rfind and rstrip. The lack of rsplit is kind of glaring in this context. Really, though, it's useful because otherwise people have to implement -- often badly. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-07 14:49 Message: Logged In: YES user_id=21627 Why is this function useful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=801847&group_id=5470 From noreply at sourceforge.net Mon Sep 22 10:36:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 22 10:36:29 2003 Subject: [Patches] [ python-Patches-810242 ] Typos (words repeated twice, etc.) Message-ID: Patches item #810242, was opened at 2003-09-21 14:32 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810242&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sergey Svishchev (shattered) >Assigned to: Raymond Hettinger (rhettinger) Summary: Typos (words repeated twice, etc.) Initial Comment: A Perl one-liner from FMTEYEWTK found a number of sentences where one word is repeated twice in a row. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810242&group_id=5470 From noreply at sourceforge.net Mon Sep 22 11:29:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 22 11:29:52 2003 Subject: [Patches] [ python-Patches-810242 ] Typos (words repeated twice, etc.) Message-ID: Patches item #810242, was opened at 2003-09-21 14:32 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810242&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Sergey Svishchev (shattered) Assigned to: Raymond Hettinger (rhettinger) Summary: Typos (words repeated twice, etc.) Initial Comment: A Perl one-liner from FMTEYEWTK found a number of sentences where one word is repeated twice in a row. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-22 10:29 Message: Logged In: YES user_id=80475 Accepted and applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810242&group_id=5470 From noreply at sourceforge.net Mon Sep 22 12:43:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 22 12:43:44 2003 Subject: [Patches] [ python-Patches-764217 ] Fix for tkFont.Font(name=...) Message-ID: Patches item #764217, was opened at 2003-07-01 14:14 Message generated for change (Comment added) made by reowen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764217&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Martin v. L?wis (loewis) Summary: Fix for tkFont.Font(name=...) Initial Comment: tkFont.Font(name=xxx) crashes if a font by the specified name already exists. This is a problem for several reasons, the main one being that it makes life really tough if you want to creat a new tkFont.Font object for a given Tcl named font. This simple fix handles the problem. I've also included a new method __eq__ so that two tkFont.Font objects that point to the same Tcl named font compare as equal. I felt this is important because the fix makes it easier to have multiple such tkFont.Font objects. ---------------------------------------------------------------------- >Comment By: Russell Owen (reowen) Date: 2003-09-22 09:43 Message: Logged In: YES user_id=431773 I'm quite willing to do more work on this. I agree with the criticisms (though I'm curious how name conflicts are presently handled for widgets when the name argument is used). I think the best solution for getting a font from a font name is "nameToFont". This matches the existing "nameToWdg". (I'd also like to add a "nameToVar" or "nameToVariable", so one standard mechanism handles everything, but I digress). Unfortunately, tkFont is an add-on package. I'm not sure how tk.nameToFont can be written, given that normally a tk object won't automatically have any idea about fonts. Do you have any suggestion for handling this? Could we just start importing tkFont as a standard part of Tkinter? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-20 04:01 Message: Logged In: YES user_id=21627 reowen, are you willing to revise the patch in this direction? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-13 08:57 Message: Logged In: YES user_id=21627 While the bug might be worth fixing, I think the approach taken is wrong. With the patch, it will invoke "font names" for all new tkFont objects, which might be a significant overhead. To really preserve current behaviour, it should continue to 'font create', and fall back to 'font configure' in case of an exception. Actually, it is not clear what the right behaviour is in the first place. 'font configure' would change the settings of the existing font. If the name clash is by coincidence, it would be better to raise an exception instead of silently modifying the existing font. In the face of ambiguity, refuse the temptation to guess. So to really fix this, tkFont.forName (or tkFont.existing) should be provided. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-13 08:32 Message: Logged In: YES user_id=80475 The first part of the patch appears reasonable. For the second part, it's a bit late for an API change. Martin, is this bugfix okay for Py2.3? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764217&group_id=5470 From noreply at sourceforge.net Mon Sep 22 13:05:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 22 13:05:44 2003 Subject: [Patches] [ python-Patches-764217 ] Fix for tkFont.Font(name=...) Message-ID: Patches item #764217, was opened at 2003-07-01 14:14 Message generated for change (Comment added) made by reowen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764217&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Martin v. L?wis (loewis) Summary: Fix for tkFont.Font(name=...) Initial Comment: tkFont.Font(name=xxx) crashes if a font by the specified name already exists. This is a problem for several reasons, the main one being that it makes life really tough if you want to creat a new tkFont.Font object for a given Tcl named font. This simple fix handles the problem. I've also included a new method __eq__ so that two tkFont.Font objects that point to the same Tcl named font compare as equal. I felt this is important because the fix makes it easier to have multiple such tkFont.Font objects. ---------------------------------------------------------------------- >Comment By: Russell Owen (reowen) Date: 2003-09-22 10:05 Message: Logged In: YES user_id=431773 Here is a proposed approach to handle the exists problem. Supply a new argument to Font: exists. If False, the existing behavior is used; if True, existence is checked and the font configured (if any config info supplied). This makes it trivial to write "nameToFont" (it also makes it unnecessary, but I really think it is desirable). The issue of how to make nameToFont a method of tk objects remains. I'd love to import tkFont (font objects should be more visible) but obviously permission is needed for such a step. Anyway, what do you think? Is it permissable to add the "exists" argument to Font.__init__? ---------------------------------------------------------------------- Comment By: Russell Owen (reowen) Date: 2003-09-22 09:43 Message: Logged In: YES user_id=431773 I'm quite willing to do more work on this. I agree with the criticisms (though I'm curious how name conflicts are presently handled for widgets when the name argument is used). I think the best solution for getting a font from a font name is "nameToFont". This matches the existing "nameToWdg". (I'd also like to add a "nameToVar" or "nameToVariable", so one standard mechanism handles everything, but I digress). Unfortunately, tkFont is an add-on package. I'm not sure how tk.nameToFont can be written, given that normally a tk object won't automatically have any idea about fonts. Do you have any suggestion for handling this? Could we just start importing tkFont as a standard part of Tkinter? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-20 04:01 Message: Logged In: YES user_id=21627 reowen, are you willing to revise the patch in this direction? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-13 08:57 Message: Logged In: YES user_id=21627 While the bug might be worth fixing, I think the approach taken is wrong. With the patch, it will invoke "font names" for all new tkFont objects, which might be a significant overhead. To really preserve current behaviour, it should continue to 'font create', and fall back to 'font configure' in case of an exception. Actually, it is not clear what the right behaviour is in the first place. 'font configure' would change the settings of the existing font. If the name clash is by coincidence, it would be better to raise an exception instead of silently modifying the existing font. In the face of ambiguity, refuse the temptation to guess. So to really fix this, tkFont.forName (or tkFont.existing) should be provided. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-13 08:32 Message: Logged In: YES user_id=80475 The first part of the patch appears reasonable. For the second part, it's a bit late for an API change. Martin, is this bugfix okay for Py2.3? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764217&group_id=5470 From noreply at sourceforge.net Mon Sep 22 14:26:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 22 14:27:30 2003 Subject: [Patches] [ python-Patches-810751 ] Fix many doc typos Message-ID: Patches item #810751, was opened at 2003-09-22 20:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810751&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Raymond Hettinger (rhettinger) Summary: Fix many doc typos Initial Comment: This patch fixes many documentation and docstring typos related to duplicate words. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810751&group_id=5470 From noreply at sourceforge.net Mon Sep 22 14:30:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 22 14:30:22 2003 Subject: [Patches] [ python-Patches-810754 ] socket.ssl should check certificates Message-ID: Patches item #810754, was opened at 2003-09-22 20:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810754&group_id=5470 Category: Modules Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Damjan Georgievski (gdamjan) Assigned to: Nobody/Anonymous (nobody) Summary: socket.ssl should check certificates Initial Comment: I've decided to post here the patch proposed by Ed Phillips, since I think it's simple addition to the socket.ssl that will drastically increase its usefullness... The point of the patch is for a socket.ssl object to check the certificate received by the peer. http://mail.python.org/pipermail/python-list/2003-July/174933.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810754&group_id=5470 From noreply at sourceforge.net Mon Sep 22 15:10:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 22 15:10:30 2003 Subject: [Patches] [ python-Patches-810751 ] Fix many doc typos Message-ID: Patches item #810751, was opened at 2003-09-22 13:26 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810751&group_id=5470 Category: None Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) >Assigned to: Walter D?rwald (doerwalter) Summary: Fix many doc typos Initial Comment: This patch fixes many documentation and docstring typos related to duplicate words. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-22 14:10 Message: Logged In: YES user_id=80475 Go ahead and apply these. Also, backport to 2.3.1 if you have time. I had already fixed a couple of them but most are new. Be sure to whitespace normalize the *.py files in the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810751&group_id=5470 From noreply at sourceforge.net Mon Sep 22 21:18:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 22 21:18:44 2003 Subject: [Patches] [ python-Patches-810914 ] fix for mkstemp with relative paths (bug #810408) Message-ID: Patches item #810914, was opened at 2003-09-23 03:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810914&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Bartl (midramas) Assigned to: Nobody/Anonymous (nobody) Summary: fix for mkstemp with relative paths (bug #810408) Initial Comment: Fixed: - Added a testcase to test_tempfile.py to catch the bug - Fixed mkstemp() to return absolute pathname Bug description: The document of tempfile.mkstemp says that, "mkstemp() returns a tuple containing an OS-level handle to an open file (as would be returned by os.open()) and the absolute pathname of that file, in that order." However, if you specify the directory as relative path, it doesn't return an absolute pathname. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810914&group_id=5470 From noreply at sourceforge.net Tue Sep 23 10:58:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 23 10:58:38 2003 Subject: [Patches] [ python-Patches-806800 ] NetBSD py_curses.h fix Message-ID: Patches item #806800, was opened at 2003-09-15 22:47 Message generated for change (Comment added) made by marc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=806800&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: NetBSD py_curses.h fix Initial Comment: On NetBSD, [n]curses.h and stdlib.h/wchar.h use different guards against multiple definition of wchar_t and wint_t. ---------------------------------------------------------------------- >Comment By: Marc Recht (marc) Date: 2003-09-23 16:58 Message: Logged In: YES user_id=205 Oh. I think we're talking at cross-purposes. The _system_ curses isn't used, it's GNU ncurses. And ncurses and char.h clash if _XOPEN_SOURCE_EXTENDED is defined. Naturally the system curses and wchar.h could be included together. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-19 00:45 Message: Logged In: YES user_id=21627 Is it the case that curses.h and wchar.h cannot be simultaneously be included if a certain supported #define is given? If so, it is clearly a bug in the header files - it should not be possible to get conflicting declarations by just including system headers. Even if it applies to all released versions of the system, I still need an explicit list of what these versions are, and I need a compile-time failure if a version is encountered that isn't listed. That the next release is only a year away is a good thing - maybe they can fix the bug until then. They won't, of course, fix the bug if nobody tells them there is a bug... ---------------------------------------------------------------------- Comment By: Marc Recht (marc) Date: 2003-09-18 23:51 Message: Logged In: YES user_id=205 Hmm. I won't consider it a bug in NetBSD. Just a clash of declarations.. ;-) The attached patch is needed for 1.6.x and -current (which will be released not sooner than next year). I'm not sure about 1.5, but I'd bet it's the same. So, there's just no restriction possible. It's simply - all - (if _XOPEN_SOURCE_EXTENDED is defined). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-18 20:33 Message: Logged In: YES user_id=21627 That is a work around a NetBSD bug, right? If so, there should be some procedure to retest presence of the bug in new NetBSD releases, and record the versions for which the bug has been found to be present. Then, when the newest release with the bug is not supported in Python anymore, the code can be removed (which might well be 10 years from now). If possible, a code fragment like #if (NetBSD_major == 3) or (NetBSD_major==4) // bug present, add work-around #else #error Please check whether the bug is still present #endif ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=806800&group_id=5470 From noreply at sourceforge.net Tue Sep 23 13:23:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 23 13:23:47 2003 Subject: [Patches] [ python-Patches-788509 ] Glossary Message-ID: Patches item #788509, was opened at 2003-08-13 23:04 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788509&group_id=5470 Category: Documentation >Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Skip Montanaro (montanaro) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Glossary Initial Comment: The topic of iterables came up on c.l.py recently. One of the participants mentioned that "iterable" isn't listed in the index of either the language or library reference manuals. A quick search didn't yield any obvious definition of what an iterable is. (There may be something I missed. I wasn't terribly thorough in my search.) The attached patch attempts to fix that omission by adding a glossary to the language reference manual. Maybe it should be a separate manual. It doesn't seem like it belongs in the tutorial, and the library reference manual doesn't cover the language itself. Keep, toss, throw darts at, or pass back for action. S ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-17 10:45 Message: Logged In: YES user_id=80475 I recommend putting it in the tutorial. As it stands now, the glossary can be profitability read A to Z after completing the tutorial. It can serve to unify and solidify the ideas presented up to that point. The reference manual is more encyclopedic and I think the glossary would be lost in a sea of entries. Another alternative is to make it a stand-alone link from the main page: Tutorial (start here) Ref Manual Lib Ref Glossary of Key Concepts This patch is marked for Py2.4. I recommend that it be added to Py2.3.1 also. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-17 09:50 Message: Logged In: YES user_id=44345 Agreed, it has been quite successful. Fred, I'll take this over if you like, but I'd sort of like a pronouncement about where the glossary should go. My thought was that it would be an appendix to the language reference manual. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-17 00:20 Message: Logged In: YES user_id=80475 The wiki was a success and the glossary looks ready for prime-time. So go ahead and add it (or assign to me). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-14 08:29 Message: Logged In: YES user_id=44345 Agreed. Any glossary with only one entry would be a bit thin. Thanks for the new entry. :-) ---------------------------------------------------------------------- Comment By: Duncan Booth (duncanb) Date: 2003-08-14 03:33 Message: Logged In: YES user_id=74031 Sorry, but I'm going to throw darts at this. You need to have glossary entries for both 'iterable' and 'iterator', and you're current definition of 'iterable' is actually the definition of 'iterator' not of 'iterable'. Try something like this: \index{iterable{ \item[iterable] Any object which supports enumeration of a set of values by calling its \method{__iter__} which returns an iterator over those values. Examples include \class{file}, \class{list} and \class{dict} objects. In the case of \class {dict} objects, iteration is over the keys in the object. \index{iterator} \item[iterator] An object which supports enumeration of a set of values by calling its \method{next} method and which contains an \method{__iter__} method which returns the object itself. Examples: \class{file} is a iterable which is its own iterator. \class{list} and \class{dict} are iterables which create iterators of types which are not otherwise visible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788509&group_id=5470 From noreply at sourceforge.net Tue Sep 23 13:31:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 23 13:31:18 2003 Subject: [Patches] [ python-Patches-806800 ] NetBSD py_curses.h fix Message-ID: Patches item #806800, was opened at 2003-09-15 22:47 Message generated for change (Comment added) made by marc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=806800&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: NetBSD py_curses.h fix Initial Comment: On NetBSD, [n]curses.h and stdlib.h/wchar.h use different guards against multiple definition of wchar_t and wint_t. ---------------------------------------------------------------------- >Comment By: Marc Recht (marc) Date: 2003-09-23 19:31 Message: Logged In: YES user_id=205 Just one note that might clarify things a bit more... ncurses is installed with the pkgsrc system (like FreeBSD's ports). It doesn't get installed with the base system nor is it in one of the system directories. (It's in /usr/pkg.) NetBSD has a curses implementation, but it has not (yet) all the features Python needs. Because of that we use GNU ncurses (atm 5.3). ---------------------------------------------------------------------- Comment By: Marc Recht (marc) Date: 2003-09-23 16:58 Message: Logged In: YES user_id=205 Oh. I think we're talking at cross-purposes. The _system_ curses isn't used, it's GNU ncurses. And ncurses and char.h clash if _XOPEN_SOURCE_EXTENDED is defined. Naturally the system curses and wchar.h could be included together. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-19 00:45 Message: Logged In: YES user_id=21627 Is it the case that curses.h and wchar.h cannot be simultaneously be included if a certain supported #define is given? If so, it is clearly a bug in the header files - it should not be possible to get conflicting declarations by just including system headers. Even if it applies to all released versions of the system, I still need an explicit list of what these versions are, and I need a compile-time failure if a version is encountered that isn't listed. That the next release is only a year away is a good thing - maybe they can fix the bug until then. They won't, of course, fix the bug if nobody tells them there is a bug... ---------------------------------------------------------------------- Comment By: Marc Recht (marc) Date: 2003-09-18 23:51 Message: Logged In: YES user_id=205 Hmm. I won't consider it a bug in NetBSD. Just a clash of declarations.. ;-) The attached patch is needed for 1.6.x and -current (which will be released not sooner than next year). I'm not sure about 1.5, but I'd bet it's the same. So, there's just no restriction possible. It's simply - all - (if _XOPEN_SOURCE_EXTENDED is defined). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-18 20:33 Message: Logged In: YES user_id=21627 That is a work around a NetBSD bug, right? If so, there should be some procedure to retest presence of the bug in new NetBSD releases, and record the versions for which the bug has been found to be present. Then, when the newest release with the bug is not supported in Python anymore, the code can be removed (which might well be 10 years from now). If possible, a code fragment like #if (NetBSD_major == 3) or (NetBSD_major==4) // bug present, add work-around #else #error Please check whether the bug is still present #endif ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=806800&group_id=5470 From noreply at sourceforge.net Wed Sep 24 09:09:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 24 09:13:11 2003 Subject: [Patches] [ python-Patches-788509 ] Glossary Message-ID: Patches item #788509, was opened at 2003-08-13 23:04 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788509&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Skip Montanaro (montanaro) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Glossary Initial Comment: The topic of iterables came up on c.l.py recently. One of the participants mentioned that "iterable" isn't listed in the index of either the language or library reference manuals. A quick search didn't yield any obvious definition of what an iterable is. (There may be something I missed. I wasn't terribly thorough in my search.) The attached patch attempts to fix that omission by adding a glossary to the language reference manual. Maybe it should be a separate manual. It doesn't seem like it belongs in the tutorial, and the library reference manual doesn't cover the language itself. Keep, toss, throw darts at, or pass back for action. S ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-09-24 08:09 Message: Logged In: YES user_id=44345 I'm going to put this in the tutorial as Raymond suggested. It would be nice if there was a special \glossaryitem{} environment that would allow easy linking to glossary entries from other places in the documentation. I'm not going to let its absence hold me up. It's just something to consider. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-17 10:45 Message: Logged In: YES user_id=80475 I recommend putting it in the tutorial. As it stands now, the glossary can be profitability read A to Z after completing the tutorial. It can serve to unify and solidify the ideas presented up to that point. The reference manual is more encyclopedic and I think the glossary would be lost in a sea of entries. Another alternative is to make it a stand-alone link from the main page: Tutorial (start here) Ref Manual Lib Ref Glossary of Key Concepts This patch is marked for Py2.4. I recommend that it be added to Py2.3.1 also. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-17 09:50 Message: Logged In: YES user_id=44345 Agreed, it has been quite successful. Fred, I'll take this over if you like, but I'd sort of like a pronouncement about where the glossary should go. My thought was that it would be an appendix to the language reference manual. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-17 00:20 Message: Logged In: YES user_id=80475 The wiki was a success and the glossary looks ready for prime-time. So go ahead and add it (or assign to me). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-14 08:29 Message: Logged In: YES user_id=44345 Agreed. Any glossary with only one entry would be a bit thin. Thanks for the new entry. :-) ---------------------------------------------------------------------- Comment By: Duncan Booth (duncanb) Date: 2003-08-14 03:33 Message: Logged In: YES user_id=74031 Sorry, but I'm going to throw darts at this. You need to have glossary entries for both 'iterable' and 'iterator', and you're current definition of 'iterable' is actually the definition of 'iterator' not of 'iterable'. Try something like this: \index{iterable{ \item[iterable] Any object which supports enumeration of a set of values by calling its \method{__iter__} which returns an iterator over those values. Examples include \class{file}, \class{list} and \class{dict} objects. In the case of \class {dict} objects, iteration is over the keys in the object. \index{iterator} \item[iterator] An object which supports enumeration of a set of values by calling its \method{next} method and which contains an \method{__iter__} method which returns the object itself. Examples: \class{file} is a iterable which is its own iterator. \class{list} and \class{dict} are iterables which create iterators of types which are not otherwise visible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788509&group_id=5470 From noreply at sourceforge.net Wed Sep 24 13:02:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 24 13:02:05 2003 Subject: [Patches] [ python-Patches-788509 ] Glossary Message-ID: Patches item #788509, was opened at 2003-08-13 23:04 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788509&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Skip Montanaro (montanaro) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Glossary Initial Comment: The topic of iterables came up on c.l.py recently. One of the participants mentioned that "iterable" isn't listed in the index of either the language or library reference manuals. A quick search didn't yield any obvious definition of what an iterable is. (There may be something I missed. I wasn't terribly thorough in my search.) The attached patch attempts to fix that omission by adding a glossary to the language reference manual. Maybe it should be a separate manual. It doesn't seem like it belongs in the tutorial, and the library reference manual doesn't cover the language itself. Keep, toss, throw darts at, or pass back for action. S ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-09-24 12:01 Message: Logged In: YES user_id=44345 I checked in an initial glossary for the tutorial. I'm sure it will need a fair amount of LaTeX work. Fred, please feel free to ping me on that. I will be happy to do the work with some guidance from you. One thing I was hoping we could do is generate links from other documentation into the tutorial, but I have no idea how well LaTeX and latex2html support inter- document links. Another (simpler, though tedious) task will be to "indexify" the tutorial, now that one is being generated. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-24 08:09 Message: Logged In: YES user_id=44345 I'm going to put this in the tutorial as Raymond suggested. It would be nice if there was a special \glossaryitem{} environment that would allow easy linking to glossary entries from other places in the documentation. I'm not going to let its absence hold me up. It's just something to consider. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-17 10:45 Message: Logged In: YES user_id=80475 I recommend putting it in the tutorial. As it stands now, the glossary can be profitability read A to Z after completing the tutorial. It can serve to unify and solidify the ideas presented up to that point. The reference manual is more encyclopedic and I think the glossary would be lost in a sea of entries. Another alternative is to make it a stand-alone link from the main page: Tutorial (start here) Ref Manual Lib Ref Glossary of Key Concepts This patch is marked for Py2.4. I recommend that it be added to Py2.3.1 also. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-17 09:50 Message: Logged In: YES user_id=44345 Agreed, it has been quite successful. Fred, I'll take this over if you like, but I'd sort of like a pronouncement about where the glossary should go. My thought was that it would be an appendix to the language reference manual. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-17 00:20 Message: Logged In: YES user_id=80475 The wiki was a success and the glossary looks ready for prime-time. So go ahead and add it (or assign to me). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-14 08:29 Message: Logged In: YES user_id=44345 Agreed. Any glossary with only one entry would be a bit thin. Thanks for the new entry. :-) ---------------------------------------------------------------------- Comment By: Duncan Booth (duncanb) Date: 2003-08-14 03:33 Message: Logged In: YES user_id=74031 Sorry, but I'm going to throw darts at this. You need to have glossary entries for both 'iterable' and 'iterator', and you're current definition of 'iterable' is actually the definition of 'iterator' not of 'iterable'. Try something like this: \index{iterable{ \item[iterable] Any object which supports enumeration of a set of values by calling its \method{__iter__} which returns an iterator over those values. Examples include \class{file}, \class{list} and \class{dict} objects. In the case of \class {dict} objects, iteration is over the keys in the object. \index{iterator} \item[iterator] An object which supports enumeration of a set of values by calling its \method{next} method and which contains an \method{__iter__} method which returns the object itself. Examples: \class{file} is a iterable which is its own iterator. \class{list} and \class{dict} are iterables which create iterators of types which are not otherwise visible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788509&group_id=5470 From noreply at sourceforge.net Wed Sep 24 18:35:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 24 18:35:55 2003 Subject: [Patches] [ python-Patches-662475 ] 642391: tempfile.mktemp() docs to include dir info Message-ID: Patches item #662475, was opened at 2003-01-05 05:41 Message generated for change (Comment added) made by midramas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662475&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christopher Blunck (blunck2) Assigned to: Nobody/Anonymous (nobody) Summary: 642391: tempfile.mktemp() docs to include dir info Initial Comment: added text that states that if a directory is not provided to mktemp(), the system wide temporary directory, or a suitable unique directory name is prepended to the filename ---------------------------------------------------------------------- Comment By: Michael Bartl (midramas) Date: 2003-09-25 00:35 Message: Logged In: YES user_id=31511 I'd propose to close this patch due to the reasons given in the comment from M.v. Loewis. Additionaly the tempfile.mktemp() has been marked deprecated as of Python 2.3. The same procedure could be applied to the original bug #642391 since adding documentation to an insecure deprecated function only gives the developers more choices on blasting their systems. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-01-15 13:18 Message: Logged In: YES user_id=21627 I don't think this patch addresses the concern of bug 642391. The issue is not in which directory the temporary files are created, but whether the temporary files need to be files. They need not: mktemp can also be used to create temporary directories. Of course, as mktemp suffers from security problems, using mkdtemp (new in 2.3) is better to create temporary directories. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662475&group_id=5470 From noreply at sourceforge.net Thu Sep 25 04:47:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 25 04:47:45 2003 Subject: [Patches] [ python-Patches-812285 ] More precise realm parsing in AbstractBasicAuthHandler Message-ID: Patches item #812285, was opened at 2003-09-25 10:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=812285&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Federico Di Carlo (federicodc) Assigned to: Nobody/Anonymous (nobody) Summary: More precise realm parsing in AbstractBasicAuthHandler Initial Comment: AbstractBasicAuthHandler class parses headers to search for a scheme and its realm. "rx" is the compiled regular expression that is used to match these items. But it doesn't work on multiple auth-schemes (as stated in urllib2.py source code). Since I HAD to work around this issue (we have NTLM authentication first in our proxy) I managed a bit the regular expression (rx) and its groups. The auth-request I had to face is: < NTLM, Basic realm="something" >, so I created a RE with named groups to find exactly the type of request that has a "realm" after the scheme, and that can contain commas, in this way: < ([ \t]+|(.*,)+)*(?P[^ \t]+)[ \t]+realm="(?P[^"]*)"' > Matching groups "scheme" and "realm" will contain right values as parsed. This will NOT fix issue with multiple realm-based requests (it will return only last one), but seems to handle well requests like the one specified. Diff attached for Python 2.3 Hope this helps, Federico Di Carlo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=812285&group_id=5470 From noreply at sourceforge.net Thu Sep 25 06:49:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 25 06:49:59 2003 Subject: [Patches] [ python-Patches-812369 ] module shutdown procedure based on GC Message-ID: Patches item #812369, was opened at 2003-09-25 10:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=812369&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: module shutdown procedure based on GC Initial Comment: This patches changes PyImport_Cleanup() in an attempt to make the module shutdown order more predictable in the presence of modules that import each other. Before it explicitely clears the globals of the modules, it relies on the GC to try to do it more cleanly. http://mail.python.org/pipermail/python-dev/2003-September/038238.html To prevent objects with __del__ methods from keeping whole modules alive I actually replace each module with a weak reference to it in sys.modules. This allows me to find modules that remain alive after a call to PyGC_Collect(), and then go back to the old technique of clearing their globals. Note that weak references to dead cycles containing objects with finalizers have a strange property in Python: if you use the weak reference again you can break the cycles, but the objects with finalizers still won't be collected because they are in gc.garbage. As this is exactly what occurs above, I clear the gc.garbage list explicitely before the final PyGC_Collect() call. I'm not sure exactly what this might do; could it release older objects that were never put in a module but that at some time were put in gc.garbage and whose cycles were later broken? If so, is it a good thing to release them now? (Would it make sense to clear gc.garbage and call gc.collect again from time to time to check if the objects are still in a cycle?) This patch does not change the behavior of module objects clearing their globals dictionary as soon as they are deallocated. This could be work investigating. This patch puts weak references (actually proxies) in sys.modules but only at shutdown time. Moure thoughts could be given towards allowing weak references during normal program execution as well. To do so we must ensure that 'import' statements return the real module, not the weak proxy object, which is more difficult than it first seems in the presence of packages. And finally -- this patch has not really been tested, apart from the fact that it passes the test suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=812369&group_id=5470 From noreply at sourceforge.net Thu Sep 25 07:13:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 25 07:13:56 2003 Subject: [Patches] [ python-Patches-812378 ] normalize whitespace Message-ID: Patches item #812378, was opened at 2003-09-25 20:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=812378&group_id=5470 Category: Demos and tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: normalize whitespace Initial Comment: I normalized some old codes to use 4-space indent. * Lib/distutils/sysconfig.py 8-space indent was used at two places and a tab at one place. Change them into 4-space indents to be consistent with other indents. * Tools/ Change 8-space tabs into 4-space indents. Changes are made to all Python scripts except those at Tools/freeze directory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=812378&group_id=5470 From noreply at sourceforge.net Thu Sep 25 13:52:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 25 13:54:19 2003 Subject: [Patches] [ python-Patches-772077 ] small fix for setup.py Message-ID: Patches item #772077, was opened at 2003-07-16 00:13 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=772077&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: A.M. Kuchling (akuchling) Summary: small fix for setup.py Initial Comment: On UnixWare platforms readline module doesn't build because it needs -lcurses. Here is a patch that corrects this. This should also be applied to the 2.2 tree. here is the error. *** WARNING: renaming "readline" since importing it failed: dynamic linker: ./python: relocation error: symbol not found: tputs; referenced from: /usr/local/lib/libreadline.so.3 ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-09-25 13:52 Message: Logged In: YES user_id=11375 There's already an earlier bit of code that adds /usr/ccs/lib on OSF/1, so maybe it's better to just add Unixware to that test. Does the new attached patch work for you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=772077&group_id=5470 From noreply at sourceforge.net Thu Sep 25 16:02:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 25 16:02:30 2003 Subject: [Patches] [ python-Patches-772077 ] small fix for setup.py Message-ID: Patches item #772077, was opened at 2003-07-15 21:13 Message generated for change (Comment added) made by tim1470 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=772077&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: A.M. Kuchling (akuchling) Summary: small fix for setup.py Initial Comment: On UnixWare platforms readline module doesn't build because it needs -lcurses. Here is a patch that corrects this. This should also be applied to the 2.2 tree. here is the error. *** WARNING: renaming "readline" since importing it failed: dynamic linker: ./python: relocation error: symbol not found: tputs; referenced from: /usr/local/lib/libreadline.so.3 ---------------------------------------------------------------------- >Comment By: Tim Rice (tim1470) Date: 2003-09-25 13:02 Message: Logged In: YES user_id=618097 patch2 doesn't quite worlk but it's on the right track I've attached setup.py.patch3 that does work. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-09-25 10:52 Message: Logged In: YES user_id=11375 There's already an earlier bit of code that adds /usr/ccs/lib on OSF/1, so maybe it's better to just add Unixware to that test. Does the new attached patch work for you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=772077&group_id=5470 From noreply at sourceforge.net Thu Sep 25 18:30:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 25 18:30:28 2003 Subject: [Patches] [ python-Patches-662475 ] 642391: tempfile.mktemp() docs to include dir info Message-ID: Patches item #662475, was opened at 2003-01-05 05:41 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662475&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christopher Blunck (blunck2) >Assigned to: Martin v. L?wis (loewis) Summary: 642391: tempfile.mktemp() docs to include dir info Initial Comment: added text that states that if a directory is not provided to mktemp(), the system wide temporary directory, or a suitable unique directory name is prepended to the filename ---------------------------------------------------------------------- Comment By: Michael Bartl (midramas) Date: 2003-09-25 00:35 Message: Logged In: YES user_id=31511 I'd propose to close this patch due to the reasons given in the comment from M.v. Loewis. Additionaly the tempfile.mktemp() has been marked deprecated as of Python 2.3. The same procedure could be applied to the original bug #642391 since adding documentation to an insecure deprecated function only gives the developers more choices on blasting their systems. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-01-15 13:18 Message: Logged In: YES user_id=21627 I don't think this patch addresses the concern of bug 642391. The issue is not in which directory the temporary files are created, but whether the temporary files need to be files. They need not: mktemp can also be used to create temporary directories. Of course, as mktemp suffers from security problems, using mkdtemp (new in 2.3) is better to create temporary directories. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662475&group_id=5470 From noreply at sourceforge.net Fri Sep 26 13:59:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 26 13:59:34 2003 Subject: [Patches] [ python-Patches-813200 ] Fix test_tempfile: space in Win32 install path bug #811082 Message-ID: Patches item #813200, was opened at 2003-09-26 19:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=813200&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Bartl (midramas) Assigned to: Nobody/Anonymous (nobody) Summary: Fix test_tempfile: space in Win32 install path bug #811082 Initial Comment: Fix: - corrected arguments passed to spawnl function and added comment to explain tricky win32 behaviour Bug description: test_tempfile.py fails on XP (probably other platforms too) when Python is installed into \Program Files\Python2.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=813200&group_id=5470 From noreply at sourceforge.net Fri Sep 26 23:21:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 26 23:21:28 2003 Subject: [Patches] [ python-Patches-813391 ] _sre stack overflow on FreeBSD/amd64 and /sparc64 Message-ID: Patches item #813391, was opened at 2003-09-27 12:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=813391&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: _sre stack overflow on FreeBSD/amd64 and /sparc64 Initial Comment: FreeBSD/amd64 and /sparc64 require even smaller limits. (FreeBSD/ia64 is safe enough with 6500.) Please see the attachment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=813391&group_id=5470 From noreply at sourceforge.net Sat Sep 27 04:09:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 27 04:09:57 2003 Subject: [Patches] [ python-Patches-813436 ] Scalable zipfile extension Message-ID: Patches item #813436, was opened at 2003-09-27 10:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=813436&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Marc De Falco (deufeufeu) Assigned to: Nobody/Anonymous (nobody) Summary: Scalable zipfile extension Initial Comment: Playing around with large zipfiles (> 10000 files), I've encountered big loading time, even if after having loaded it I use only 30 files in it. So I've introduced a differed parameter to the Zipfile.__init__ in order to load headers on-demand. As it's not a really good idea to activated it for all zip it defaults to False. I've updated the documentation too. Thx and keep the good work ;) P.S. : Dunno if it can be added to 2.3 or have to be included in 2.4, so I've choosed 2.4 group. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=813436&group_id=5470 From noreply at sourceforge.net Sat Sep 27 04:43:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 27 04:43:25 2003 Subject: [Patches] [ python-Patches-813445 ] Add IPPROTO_IPV6 option to the socketmodule Message-ID: Patches item #813445, was opened at 2003-09-27 08:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=813445&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: Add IPPROTO_IPV6 option to the socketmodule Initial Comment: the abovementioned socket option is missing from python2.2 as well 2.3. it's needed by nearly all server programs, since i believe the default behaviour in linux changed between kernel versions 2.4 and 2.6. the default also currently varies between operating systems. it controls whether listening to * on a ipv6 socket also accepts ipv4 connections. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=813445&group_id=5470 From noreply at sourceforge.net Sat Sep 27 13:26:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 27 13:27:28 2003 Subject: [Patches] [ python-Patches-813391 ] _sre stack overflow on FreeBSD/amd64 and /sparc64 Message-ID: Patches item #813391, was opened at 2003-09-27 05:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=813391&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: _sre stack overflow on FreeBSD/amd64 and /sparc64 Initial Comment: FreeBSD/amd64 and /sparc64 require even smaller limits. (FreeBSD/ia64 is safe enough with 6500.) Please see the attachment. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-27 19:26 Message: Logged In: YES user_id=21627 The patch likely becomes obsolete when the removal of recursion in sre is implemented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=813391&group_id=5470 From noreply at sourceforge.net Sat Sep 27 13:31:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 27 13:31:46 2003 Subject: [Patches] [ python-Patches-812369 ] module shutdown procedure based on GC Message-ID: Patches item #812369, was opened at 2003-09-25 12:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=812369&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: module shutdown procedure based on GC Initial Comment: This patches changes PyImport_Cleanup() in an attempt to make the module shutdown order more predictable in the presence of modules that import each other. Before it explicitely clears the globals of the modules, it relies on the GC to try to do it more cleanly. http://mail.python.org/pipermail/python-dev/2003-September/038238.html To prevent objects with __del__ methods from keeping whole modules alive I actually replace each module with a weak reference to it in sys.modules. This allows me to find modules that remain alive after a call to PyGC_Collect(), and then go back to the old technique of clearing their globals. Note that weak references to dead cycles containing objects with finalizers have a strange property in Python: if you use the weak reference again you can break the cycles, but the objects with finalizers still won't be collected because they are in gc.garbage. As this is exactly what occurs above, I clear the gc.garbage list explicitely before the final PyGC_Collect() call. I'm not sure exactly what this might do; could it release older objects that were never put in a module but that at some time were put in gc.garbage and whose cycles were later broken? If so, is it a good thing to release them now? (Would it make sense to clear gc.garbage and call gc.collect again from time to time to check if the objects are still in a cycle?) This patch does not change the behavior of module objects clearing their globals dictionary as soon as they are deallocated. This could be work investigating. This patch puts weak references (actually proxies) in sys.modules but only at shutdown time. Moure thoughts could be given towards allowing weak references during normal program execution as well. To do so we must ensure that 'import' statements return the real module, not the weak proxy object, which is more difficult than it first seems in the presence of packages. And finally -- this patch has not really been tested, apart from the fact that it passes the test suite. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-09-27 19:31 Message: Logged In: YES user_id=21627 I think clearing gc.garbage at shutdown time is a good idea; gc.garbage is mostly a debugging aid, and should be empty in production code. If it still contains objects at shutdown time, it is IMO reasonable to give them a chance to become collected, in case somebody broke their cycles. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=812369&group_id=5470 From noreply at sourceforge.net Sun Sep 28 01:55:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 28 01:55:48 2003 Subject: [Patches] [ python-Patches-813877 ] entry size for cursors Message-ID: Patches item #813877, was opened at 2003-09-28 08:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=813877&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Itamar Shtull-Trauring (itamar) Assigned to: Nobody/Anonymous (nobody) Summary: entry size for cursors Initial Comment: If you store large entries in a database, there is currently no way to get their size without reading the whole thing into memory when using cursors. Knowing the length is useful for doing partial reads from a record. The patch adds a method get_current_size() that returns the length of the data in the current entry the cursor is pointing at. Implemented at the request of the Quotient developers (divmod.org). I have pybsddb cvs access so I can check in the docs there if/when this goes in to core python. (Patch is concatenated two files, hope it's ok.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=813877&group_id=5470 From noreply at sourceforge.net Sun Sep 28 03:37:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 28 03:37:58 2003 Subject: [Patches] [ python-Patches-788509 ] Glossary Message-ID: Patches item #788509, was opened at 2003-08-13 23:04 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788509&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Skip Montanaro (montanaro) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Glossary Initial Comment: The topic of iterables came up on c.l.py recently. One of the participants mentioned that "iterable" isn't listed in the index of either the language or library reference manuals. A quick search didn't yield any obvious definition of what an iterable is. (There may be something I missed. I wasn't terribly thorough in my search.) The attached patch attempts to fix that omission by adding a glossary to the language reference manual. Maybe it should be a separate manual. It doesn't seem like it belongs in the tutorial, and the library reference manual doesn't cover the language itself. Keep, toss, throw darts at, or pass back for action. S ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-28 02:37 Message: Logged In: YES user_id=80475 Now, the hyperlinks need to be fixed. They are all relative to the tutorial directory. Also, consider backporting the glossary to 2.3.2. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-24 12:01 Message: Logged In: YES user_id=44345 I checked in an initial glossary for the tutorial. I'm sure it will need a fair amount of LaTeX work. Fred, please feel free to ping me on that. I will be happy to do the work with some guidance from you. One thing I was hoping we could do is generate links from other documentation into the tutorial, but I have no idea how well LaTeX and latex2html support inter- document links. Another (simpler, though tedious) task will be to "indexify" the tutorial, now that one is being generated. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-24 08:09 Message: Logged In: YES user_id=44345 I'm going to put this in the tutorial as Raymond suggested. It would be nice if there was a special \glossaryitem{} environment that would allow easy linking to glossary entries from other places in the documentation. I'm not going to let its absence hold me up. It's just something to consider. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-17 10:45 Message: Logged In: YES user_id=80475 I recommend putting it in the tutorial. As it stands now, the glossary can be profitability read A to Z after completing the tutorial. It can serve to unify and solidify the ideas presented up to that point. The reference manual is more encyclopedic and I think the glossary would be lost in a sea of entries. Another alternative is to make it a stand-alone link from the main page: Tutorial (start here) Ref Manual Lib Ref Glossary of Key Concepts This patch is marked for Py2.4. I recommend that it be added to Py2.3.1 also. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-17 09:50 Message: Logged In: YES user_id=44345 Agreed, it has been quite successful. Fred, I'll take this over if you like, but I'd sort of like a pronouncement about where the glossary should go. My thought was that it would be an appendix to the language reference manual. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-17 00:20 Message: Logged In: YES user_id=80475 The wiki was a success and the glossary looks ready for prime-time. So go ahead and add it (or assign to me). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-14 08:29 Message: Logged In: YES user_id=44345 Agreed. Any glossary with only one entry would be a bit thin. Thanks for the new entry. :-) ---------------------------------------------------------------------- Comment By: Duncan Booth (duncanb) Date: 2003-08-14 03:33 Message: Logged In: YES user_id=74031 Sorry, but I'm going to throw darts at this. You need to have glossary entries for both 'iterable' and 'iterator', and you're current definition of 'iterable' is actually the definition of 'iterator' not of 'iterable'. Try something like this: \index{iterable{ \item[iterable] Any object which supports enumeration of a set of values by calling its \method{__iter__} which returns an iterator over those values. Examples include \class{file}, \class{list} and \class{dict} objects. In the case of \class {dict} objects, iteration is over the keys in the object. \index{iterator} \item[iterator] An object which supports enumeration of a set of values by calling its \method{next} method and which contains an \method{__iter__} method which returns the object itself. Examples: \class{file} is a iterable which is its own iterator. \class{list} and \class{dict} are iterables which create iterators of types which are not otherwise visible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788509&group_id=5470 From noreply at sourceforge.net Sun Sep 28 11:41:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 28 11:41:36 2003 Subject: [Patches] [ python-Patches-813877 ] entry size for bsddb cursors Message-ID: Patches item #813877, was opened at 2003-09-28 08:55 Message generated for change (Settings changed) made by itamar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=813877&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Itamar Shtull-Trauring (itamar) Assigned to: Nobody/Anonymous (nobody) >Summary: entry size for bsddb cursors Initial Comment: If you store large entries in a database, there is currently no way to get their size without reading the whole thing into memory when using cursors. Knowing the length is useful for doing partial reads from a record. The patch adds a method get_current_size() that returns the length of the data in the current entry the cursor is pointing at. Implemented at the request of the Quotient developers (divmod.org). I have pybsddb cvs access so I can check in the docs there if/when this goes in to core python. (Patch is concatenated two files, hope it's ok.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=813877&group_id=5470 From noreply at sourceforge.net Sun Sep 28 21:46:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 28 21:46:57 2003 Subject: [Patches] [ python-Patches-804543 ] invalid use of setlocale Message-ID: Patches item #804543, was opened at 2003-09-11 08:46 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804543&group_id=5470 >Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stanislav Brabec (sbrabec) Assigned to: Nobody/Anonymous (nobody) Summary: invalid use of setlocale Initial Comment: char *oldloc=setlocale(LC_CTYPE,NULL); setlocale(LC_CTYPE, "C"); setlocale(LC_CTYPE, oldloc); can cause strange problems. The glibc documentation clearly states, that you must make your own copy of the string. >From glibc docs: setlocale() RETURN VALUE ... This string may be allocated in static storage. ... It means, that subsequent call of setlocale can overwrite this string. And since glibc-2.3 it does. There is a fix. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-09-28 18:46 Message: Logged In: YES user_id=357491 'C: A Reference Manual' also suggests copying the string in fear of possible mucking with the string that is pointed to by the setlocale() call. Since this has a patch already I am changing this to a patch. And as for the patch, it does use strdup() which is not ANSI C. I know that there a couple of places that do use strdup(), but I am not sure if that is really proper. Requires asking python-dev. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804543&group_id=5470 From noreply at sourceforge.net Sun Sep 28 22:19:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 28 22:20:05 2003 Subject: [Patches] [ python-Patches-804543 ] invalid use of setlocale Message-ID: Patches item #804543, was opened at 2003-09-11 08:46 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804543&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stanislav Brabec (sbrabec) Assigned to: Nobody/Anonymous (nobody) Summary: invalid use of setlocale Initial Comment: char *oldloc=setlocale(LC_CTYPE,NULL); setlocale(LC_CTYPE, "C"); setlocale(LC_CTYPE, oldloc); can cause strange problems. The glibc documentation clearly states, that you must make your own copy of the string. >From glibc docs: setlocale() RETURN VALUE ... This string may be allocated in static storage. ... It means, that subsequent call of setlocale can overwrite this string. And since glibc-2.3 it does. There is a fix. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-09-28 19:19 Message: Logged In: YES user_id=357491 OK, I found that we have our own definition of strdup() that configure.in has used if it is not defined by the C library, so that issue is clear. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-09-28 18:46 Message: Logged In: YES user_id=357491 'C: A Reference Manual' also suggests copying the string in fear of possible mucking with the string that is pointed to by the setlocale() call. Since this has a patch already I am changing this to a patch. And as for the patch, it does use strdup() which is not ANSI C. I know that there a couple of places that do use strdup(), but I am not sure if that is really proper. Requires asking python-dev. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804543&group_id=5470 From noreply at sourceforge.net Mon Sep 29 10:29:37 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 29 10:29:53 2003 Subject: [Patches] [ python-Patches-788509 ] Glossary Message-ID: Patches item #788509, was opened at 2003-08-14 00:04 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788509&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Skip Montanaro (montanaro) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Glossary Initial Comment: The topic of iterables came up on c.l.py recently. One of the participants mentioned that "iterable" isn't listed in the index of either the language or library reference manuals. A quick search didn't yield any obvious definition of what an iterable is. (There may be something I missed. I wasn't terribly thorough in my search.) The attached patch attempts to fix that omission by adding a glossary to the language reference manual. Maybe it should be a separate manual. It doesn't seem like it belongs in the tutorial, and the library reference manual doesn't cover the language itself. Keep, toss, throw darts at, or pass back for action. S ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-09-29 10:29 Message: Logged In: YES user_id=3066 The hyperlinks are now fixed. It's up to Skip if he wants to maintain a version of this in 2.3.x, but too late for 2.3.2. Skip, please close this when you're satisfied (with the state of the glossary). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-28 03:37 Message: Logged In: YES user_id=80475 Now, the hyperlinks need to be fixed. They are all relative to the tutorial directory. Also, consider backporting the glossary to 2.3.2. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-24 13:01 Message: Logged In: YES user_id=44345 I checked in an initial glossary for the tutorial. I'm sure it will need a fair amount of LaTeX work. Fred, please feel free to ping me on that. I will be happy to do the work with some guidance from you. One thing I was hoping we could do is generate links from other documentation into the tutorial, but I have no idea how well LaTeX and latex2html support inter- document links. Another (simpler, though tedious) task will be to "indexify" the tutorial, now that one is being generated. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-24 09:09 Message: Logged In: YES user_id=44345 I'm going to put this in the tutorial as Raymond suggested. It would be nice if there was a special \glossaryitem{} environment that would allow easy linking to glossary entries from other places in the documentation. I'm not going to let its absence hold me up. It's just something to consider. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-17 11:45 Message: Logged In: YES user_id=80475 I recommend putting it in the tutorial. As it stands now, the glossary can be profitability read A to Z after completing the tutorial. It can serve to unify and solidify the ideas presented up to that point. The reference manual is more encyclopedic and I think the glossary would be lost in a sea of entries. Another alternative is to make it a stand-alone link from the main page: Tutorial (start here) Ref Manual Lib Ref Glossary of Key Concepts This patch is marked for Py2.4. I recommend that it be added to Py2.3.1 also. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-17 10:50 Message: Logged In: YES user_id=44345 Agreed, it has been quite successful. Fred, I'll take this over if you like, but I'd sort of like a pronouncement about where the glossary should go. My thought was that it would be an appendix to the language reference manual. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-17 01:20 Message: Logged In: YES user_id=80475 The wiki was a success and the glossary looks ready for prime-time. So go ahead and add it (or assign to me). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-14 09:29 Message: Logged In: YES user_id=44345 Agreed. Any glossary with only one entry would be a bit thin. Thanks for the new entry. :-) ---------------------------------------------------------------------- Comment By: Duncan Booth (duncanb) Date: 2003-08-14 04:33 Message: Logged In: YES user_id=74031 Sorry, but I'm going to throw darts at this. You need to have glossary entries for both 'iterable' and 'iterator', and you're current definition of 'iterable' is actually the definition of 'iterator' not of 'iterable'. Try something like this: \index{iterable{ \item[iterable] Any object which supports enumeration of a set of values by calling its \method{__iter__} which returns an iterator over those values. Examples include \class{file}, \class{list} and \class{dict} objects. In the case of \class {dict} objects, iteration is over the keys in the object. \index{iterator} \item[iterator] An object which supports enumeration of a set of values by calling its \method{next} method and which contains an \method{__iter__} method which returns the object itself. Examples: \class{file} is a iterable which is its own iterator. \class{list} and \class{dict} are iterables which create iterators of types which are not otherwise visible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788509&group_id=5470 From noreply at sourceforge.net Mon Sep 29 12:54:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 29 12:54:17 2003 Subject: [Patches] [ python-Patches-814560 ] deprecated modules Message-ID: Patches item #814560, was opened at 2003-09-29 18:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=814560&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Juan David Ib??ez Palomar (jdavid) Assigned to: Nobody/Anonymous (nobody) Summary: deprecated modules Initial Comment: it would be nice if the "Global Module Index" showed the deprecated modules clearly separated from the non deprecated modules ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=814560&group_id=5470 From noreply at sourceforge.net Mon Sep 29 17:59:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 29 17:59:07 2003 Subject: [Patches] [ python-Patches-814764 ] OpenBSD 3.4 requires define_xopen_source=no Message-ID: Patches item #814764, was opened at 2003-09-29 21:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=814764&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jason Ish (ish1) Assigned to: Nobody/Anonymous (nobody) Summary: OpenBSD 3.4 requires define_xopen_source=no Initial Comment: I have verified that OpenBSD 3.4 requires define_xopen_source=no just like previous versions of OpenBSD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=814764&group_id=5470