From noreply@sourceforge.net Fri Aug 1 01:26:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 17:26:38 -0700 Subject: [Patches] [ python-Patches-628301 ] Experimental Inno Setup Win32 installer Message-ID: Patches item #628301, was opened at 2002-10-24 19:59 Message generated for change (Comment added) made by bdodson_esrican You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=628301&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bruce Dodson (bdodson_esrican) Assigned to: Tim Peters (tim_one) Summary: Experimental Inno Setup Win32 installer Initial Comment: I found the Inno Setup script for Python in the Python 2.2.1 source tree, and decided to hack on it a bit. Since I didn't want to deploy a custom build of Python (wanted to use the original), one of my changes is something you won't want: instead of looking in PCBuild etc. for the files, it expects the files to be laid out the way the WISE installer does it. However it should be easy to change this back so it works against the Python VC source / build tree. Be that as it may, this version has a few changes that you may or may not want: 1) incorporates Mark Hammond's win32 libraries (but not Pythonwin) 2) deletes PYC and PYO files on uninstall, so that the install directory can be properly removed. 3) uses Inno Setup Extensions (http://www.wintax.nl/isx) to enable scripted behavior, e.g. behave differently based on whether an administrator is running the install. 4) uses wildcards to make the script shorter. I do like the original author's idea of using a Python script to generate the ISS script; that would allow the files to be listed explicitly rather than relying on wildcards as I did here. The addition of Mark's stuff is something that interests me, since I can't redistribute ActivePython and find it cumbersome to include 2 installers plus my own; however it is not necessarily something that you are going to care about. The other changes may be more interesting to you. This script is based on the one found in Python 2.2.1 source tree, but I have compiled and tested it against Python 2.2.2. To test, run the Python WISE installer and Mark's win32all installer. Then copy python22.dll etc. from system32 to Python22\sysdir. Copy the ISS file into the Python22 directory. Running the ISX compiler against python.iss. ---------------------------------------------------------------------- >Comment By: Bruce Dodson (bdodson_esrican) Date: 2003-07-31 21:26 Message: Logged In: YES user_id=533196 I've enhanced this further, to include the vcredist stuff, and to account for the directory tree changes in Python 2.3 (IDLE moved, etc). If you're interested in checking it out, I've compiled an experimental installer and published it at http://sourceforge.net/projects/avpython/, in the pythonsetup package. The updated source script is there as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=628301&group_id=5470 From noreply@sourceforge.net Fri Aug 1 05:06:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 21:06:15 -0700 Subject: [Patches] [ python-Patches-780821 ] More robust MSVC6 finder Message-ID: Patches item #780821, was opened at 2003-07-31 22:50 Message generated for change (Comment added) made by gtk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=780821&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Garth T Kidd (gtk) Assigned to: Jeremy Hylton (jhylton) Summary: More robust MSVC6 finder Initial Comment: My VS6 install on XP didn't set the r"Software\Microsoft\Devstudio\6.0\Build System" registry key relied upon by distutils.msvccompiler to find the compiler and linker executable. As a backup to the registry paths, this patch looks up the MSVCDIR environment variable and ensures its basename is appropriate for the Python build version: if self.__version == 6: matchbase = 'vc98' elif self.__version == 7: matchbase = 'vc7' Works fine on my machine, so long as I run VCVARS32.BAT, and fails appropriately if I ran the wrong VCVARS32.BAT by mistake (I have Visual Studio Net 2003 also installed). The patch should be applied to distutils/msvccompiler.py. ---------------------------------------------------------------------- >Comment By: Garth T Kidd (gtk) Date: 2003-08-01 14:06 Message: Logged In: YES user_id=59803 WARNING: the first patch contains a typo. s/nstring/string/ and you'll be fine. New version attached. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-08-01 08:09 Message: Logged In: YES user_id=31392 I've desired the same functionality in the past. ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2003-07-31 22:52 Message: Logged In: YES user_id=59803 Whups. The patch didn't attach. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=780821&group_id=5470 From noreply@sourceforge.net Fri Aug 1 05:55:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 21:55:54 -0700 Subject: [Patches] [ python-Patches-677838 ] python-mode.el: make C-c - work correctly after C-c | Message-ID: Patches item #677838, was opened at 2003-01-30 17:11 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677838&group_id=5470 Category: Demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Charles G Waldman (cgw) >Assigned to: Skip Montanaro (montanaro) Summary: python-mode.el: make C-c - work correctly after C-c | Initial Comment: If you are using python-mode in [X]Emacs and do py-execute-region and get an exception, py-up-exception (C-c -) will go to the wrong line, because the line number reported by Python is only relative to the start of the region. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-07-31 23:55 Message: Logged In: YES user_id=44345 Charles, Any chance you can generate your diff against the newest version of python-mode.el (something like 4.38)? I'm having trouble applying the patch you submitted originally, and my feeble manual attempts have so far not demonstrated that the patch (as I applied it) fixes the problem. Thx, Skip ---------------------------------------------------------------------- Comment By: Charles G Waldman (cgw) Date: 2003-01-31 10:37 Message: Logged In: YES user_id=7151 I tried uploading the patch again, and seem to have succeeded this time around. It's probably not fair to blane SF, as I think this was a case of pilot error. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-31 07:16 Message: Logged In: YES user_id=6656 There's no patch attached... I think SF is subliminally trying to push us into getting roundup ready to use. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677838&group_id=5470 From noreply@sourceforge.net Fri Aug 1 08:15:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 00:15:28 -0700 Subject: [Patches] [ python-Patches-781126 ] fix gettext NullTranslation.add_fallback typo Message-ID: Patches item #781126, was opened at 2003-07-31 23:23 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=781126&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bastian Kleineidam (calvin) >Assigned to: Martin v. Löwis (loewis) Summary: fix gettext NullTranslation.add_fallback typo Initial Comment: replace a typo where {} is used instead of [] in the NullTranslation.add_fallback methoddesc TeX macro. Diff is against CVS rev 1.20 (Tue Jul 22 00:49:11 2003 UTC) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=781126&group_id=5470 From noreply@sourceforge.net Fri Aug 1 08:16:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 00:16:50 -0700 Subject: [Patches] [ python-Patches-780821 ] More robust MSVC6 finder Message-ID: Patches item #780821, was opened at 2003-07-31 14:50 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=780821&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Garth T Kidd (gtk) Assigned to: Jeremy Hylton (jhylton) Summary: More robust MSVC6 finder Initial Comment: My VS6 install on XP didn't set the r"Software\Microsoft\Devstudio\6.0\Build System" registry key relied upon by distutils.msvccompiler to find the compiler and linker executable. As a backup to the registry paths, this patch looks up the MSVCDIR environment variable and ensures its basename is appropriate for the Python build version: if self.__version == 6: matchbase = 'vc98' elif self.__version == 7: matchbase = 'vc7' Works fine on my machine, so long as I run VCVARS32.BAT, and fails appropriately if I ran the wrong VCVARS32.BAT by mistake (I have Visual Studio Net 2003 also installed). The patch should be applied to distutils/msvccompiler.py. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 09:16 Message: Logged In: YES user_id=21627 I'm curious, though, how you installed VS6 without getting the registry settings. Doesn't this mean your installation of VS6 is broken? ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2003-08-01 06:06 Message: Logged In: YES user_id=59803 WARNING: the first patch contains a typo. s/nstring/string/ and you'll be fine. New version attached. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-08-01 00:09 Message: Logged In: YES user_id=31392 I've desired the same functionality in the past. ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2003-07-31 14:52 Message: Logged In: YES user_id=59803 Whups. The patch didn't attach. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=780821&group_id=5470 From noreply@sourceforge.net Fri Aug 1 18:24:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 10:24:12 -0700 Subject: [Patches] [ python-Patches-677838 ] python-mode.el: make C-c - work correctly after C-c | Message-ID: Patches item #677838, was opened at 2003-01-30 23:11 Message generated for change (Comment added) made by cgw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677838&group_id=5470 Category: Demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Charles G Waldman (cgw) Assigned to: Skip Montanaro (montanaro) Summary: python-mode.el: make C-c - work correctly after C-c | Initial Comment: If you are using python-mode in [X]Emacs and do py-execute-region and get an exception, py-up-exception (C-c -) will go to the wrong line, because the line number reported by Python is only relative to the start of the region. ---------------------------------------------------------------------- >Comment By: Charles G Waldman (cgw) Date: 2003-08-01 17:24 Message: Logged In: YES user_id=7151 updated patch ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 04:55 Message: Logged In: YES user_id=44345 Charles, Any chance you can generate your diff against the newest version of python-mode.el (something like 4.38)? I'm having trouble applying the patch you submitted originally, and my feeble manual attempts have so far not demonstrated that the patch (as I applied it) fixes the problem. Thx, Skip ---------------------------------------------------------------------- Comment By: Charles G Waldman (cgw) Date: 2003-01-31 16:37 Message: Logged In: YES user_id=7151 I tried uploading the patch again, and seem to have succeeded this time around. It's probably not fair to blane SF, as I think this was a case of pilot error. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-31 13:16 Message: Logged In: YES user_id=6656 There's no patch attached... I think SF is subliminally trying to push us into getting roundup ready to use. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677838&group_id=5470 From noreply at sourceforge.net Mon Aug 4 07:16:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 4 09:16:17 2003 Subject: [Patches] [ python-Patches-782810 ] typo in libfuture.tex Message-ID: Patches item #782810, was opened at 2003-08-04 22:16 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=782810&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 in libfuture.tex Initial Comment: "statement" was misspelled at one place in libfuture.tex. "Each statment" should be "Each statement". I've attached a patch file to fix this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=782810&group_id=5470 From noreply at sourceforge.net Mon Aug 4 14:02:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 4 16:02:42 2003 Subject: [Patches] [ python-Patches-783050 ] pty.fork() compatibility code wrong? Message-ID: Patches item #783050, was opened at 2003-08-05 06: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=783050&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Patrick Lynch (rvdp) Assigned to: Nobody/Anonymous (nobody) Summary: pty.fork() compatibility code wrong? Initial Comment: pty.fork() provides compatibility code for environments lacking os.forkpty() This code is incorrect compared to the forkpty code in glibc, and will cause reading of the returned master_fd to hang indefinetly when the child process is finished. I am running on linux, Python 2.2. I am using the compatibility code where I need more control ( grabing stdout seperate to stderr, which is on the pty). To have it read like forkpty in glibc: master_fd, slave_fd = openpty() pid = os.fork() if pid == CHILD: # Establish a new session. os.setsid() os.close(master_fd) # Slave becomes stdin/stdout/stderr of child. os.dup2(slave_fd, STDIN_FILENO) os.dup2(slave_fd, STDOUT_FILENO) os.dup2(slave_fd, STDERR_FILENO) if (slave_fd > STDERR_FILENO): os.close (slave_fd) else:#PARENT os.close( slave_fd) # Parent and child process. return pid, master_fd Reading the master_fd when the child is finished will now raise an IO error, same as the native forkpty(). I guess the story may be different on non linux boxen Patrick. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=783050&group_id=5470 From noreply at sourceforge.net Mon Aug 4 18:18:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 4 20:18:48 2003 Subject: [Patches] [ python-Patches-783188 ] support for server side transactions in _ssl Message-ID: Patches item #783188, was opened at 2003-08-05 02: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=783188&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ilario Nardinocchi (illo) Assigned to: Nobody/Anonymous (nobody) Summary: support for server side transactions in _ssl Initial Comment: Added a parameter (server_mode, type int) to the newPySSLObject() function. If its value is non-zero, a server SSL transaction is attempted - by using SSL_accept() instead of SSL_connect(). Also, the parameter has been added to the PySocket_ssl() constructor function (it defaults to 0 for compatibility) and the ssl() documentation reflects the change. A new python function has been added (pending(), C function PySSL_SSLpending()), which calls SSL_pending() and returns its return value as a python integer. Added documentation for this one, too. The return value is the number of bytes still to be read from the input buffer, so that if it's greater than zero it is useless to call a select() in a nonblocking scenery. Trivial patch but it's the only way to code an SSL server without third-party stuff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=783188&group_id=5470 From noreply at sourceforge.net Mon Aug 4 21:23:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 4 23:24:02 2003 Subject: [Patches] [ python-Patches-574750 ] Make python-mode.el use "jython" interp Message-ID: Patches item #574750, was opened at 2002-06-27 14:38 Message generated for change (Settings changed) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=574750&group_id=5470 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Kevin J. Butler (kevinbutler) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Make python-mode.el use "jython" interp Initial Comment: I believe it is time to start using the "jython" interpreter by default, rather than the "jpython" interpreter. This patch does it in a minimal way, just changing the command and acknowledging the two names. (I still prefer the JPython name, but...) ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-08-04 22:23 Message: Logged In: YES user_id=44345 migrating to the new python-mode project. follow it here: https://sourceforge.net/tracker/ index.php?func=detail&aid=783248&group_id=86916&ati d=581351 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-07-28 11:00 Message: Logged In: YES user_id=21627 Please use context or unified diffs for patches; I'm attaching your change as a diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=574750&group_id=5470 From noreply at sourceforge.net Mon Aug 4 21:27:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 4 23:27:05 2003 Subject: [Patches] [ python-Patches-575774 ] python-mode patch for ipython support Message-ID: Patches item #575774, was opened at 2002-06-30 17:28 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=575774&group_id=5470 Category: Demos and tools Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Alexander Schmolck (aschmolck) Assigned to: Barry A. Warsaw (bwarsaw) Summary: python-mode patch for ipython support Initial Comment: This patch makes the prompt and traceback recognition mechanisms a bit more flexible to allow easy adaptation for ipython (in lieu of the normal python shell). The seperate file ipython.el (which I assume will end up in the ipython distribution) then enables py-execute-region, py-up-exception etc. to work just as well for ipython (which means ipython works just as well under python mode as the standard python shell). I also added something to ipython.el to convert ipython session bits to something that looks like normal interactive session bits. This, together with ipython's ability to directly execute such strings (by auto-removing leading '>>>'s) should make for very convinient doctest development (I had orginally planned to patch python-mode to incorporate such functionality because I found the manual reediting a bit tiresome). Slightly off-topic, I also have a feature request: executing a whole file ends up creating a temporary file which is instead executed. I think it would be much nicer if the actual file itself where executed with execfile, because otherwise pdb ends up pointing to the "wrong" (i.e. the temporary) buffer. It is really easy to forget about this and edit this temporary file during a debugging session and as a consequence inadvertenly loose changes. This situation crops up quite often, if one uses ipython's really nifty feature to toggle pdb activation on exceptions (or hacks up something equivalent for python), which is an extremely efficient way to quickly debug and test one's program. I would have added a patch, but some restructuring seemed necessary, and it wasn't immediately clear to me in which way this should be done. alex ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-08-04 22:27 Message: Logged In: YES user_id=44345 migrated to new python-mode project. follow it here: https://sourceforge.net/tracker/ index.php?func=detail&aid=783254&group_id=86916&ati d=581351 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=575774&group_id=5470 From noreply at sourceforge.net Mon Aug 4 21:30:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 4 23:30:20 2003 Subject: [Patches] [ python-Patches-675034 ] More flexible py-shell interpreter selection Message-ID: Patches item #675034, was opened at 2003-01-26 13:20 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675034&group_id=5470 Category: Demos and tools Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Michael Haggerty (mhagger) Assigned to: Nobody/Anonymous (nobody) Summary: More flexible py-shell interpreter selection Initial Comment: Currently in python-mode.el, py-which-shell (the command used to start the python interpreter) is limited to "python" or "jpython". This patch makes it possible to specify an arbitrary command at invocation time, including a command that is specified relative to the current path. The problem: I am working on a project where jython is embedded within our application. The application optionally allows console access to the jython interpreter. The application is started by running a shell script which sets some environment variables then invokes the jython interpreter with a large number of arguments. I would like to use py-shell within emacs to interact with the application. However, it is impractical to start the application under py-shell for two reasons: 1. The command that needs to be invoked is neither "python" nor "jython", and in fact would require many arguments; 2. The command is not necessary installed in the PATH. Similar problems occur even if one sometimes wants to start an alternative python interpreter (such as "python2" under redhat) or an interpreter that is not in PATH (for example, if testing a new version of python). Therefore I have written a patch to python-mode.py that changes the py-shell command as follows: + If there is no prefix argument, the usual python (or jython) interpreter is invoked without further interaction as before. + If there is a prefix argument, then the user is asked what command to invoke with the "standard command" as the default input: command: python -i The user can edit the command to run whatever s/he wants. + The command typed by the user is invoked via "$SHELL -c 'COMMAND'" so that the user's program is first sought in the emacs default directory (generally, the directory related to the current emacs buffer). This allows the user to type, for example, command: ./my_test_interpreter -i I am a novice at emacs lisp, but the patch is simple (only about 10 lines changed) and it seems to work for me. The patch applies to the CVS version of python-mode.el as of today (2003-01-26), but the same patch can be applied to the version that was released with Python-2.1. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-08-04 22:30 Message: Logged In: YES user_id=44345 migrated to python-mode project. follow it here: https://sourceforge.net/tracker/ index.php?func=detail&aid=783259&group_id=86916&ati d=581351 ---------------------------------------------------------------------- Comment By: Michael Haggerty (mhagger) Date: 2003-02-03 04:45 Message: Logged In: YES user_id=38106 The two patches are largely orthogonal. This patch would provide a workaround until patch 574750 is implemented and also a fallback for people who still want to invoke "jpython" rather than "jython". If the implementer decides to remove the whole "py-toggle-shells" mechanism, then this patch would be a kind of substitute, but I am not advocating that change. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-02 12:11 Message: Logged In: YES user_id=33168 How does this relate to patch 574750? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675034&group_id=5470 From noreply at sourceforge.net Mon Aug 4 21:36:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 4 23:36:03 2003 Subject: [Patches] [ python-Patches-779839 ] python-mode py-execute-buffer bug Message-ID: Patches item #779839, was opened at 2003-07-29 15:29 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=779839&group_id=5470 Category: Demos and tools Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Skip Montanaro (montanaro) Summary: python-mode py-execute-buffer bug Initial Comment: The rest of this report is a quote from Skip's message in c.l.py. Attached is Skip's tentative patch (which is likely incorrect for Jython). --------------------------------- John> 1. Why do I get this in my minibuffer when I do John> C-c C-c in a python-mode buffer containing the John> following valid Python code? John> Wrong type argument: sequencep, cpython It looks like a bug in py-execute-region. It sets the shell variable like so: (setq shell (or (py-choose-shell-by-shebang) (py-choose-shell-by-import) py-which-shell)))) which gives it the value (quote cpython). Later on it tries to concatenate it: (let ((cmd (concat shell (if (string-equal py-which-bufname "JPython") " -" "")))) which fails because shell is not a string (strictly speaking, a sequence) at that point. I'm not sure what the correct fix is. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-08-04 22:35 Message: Logged In: YES user_id=44345 migrated to python-mode project. follow it here: https://sourceforge.net/tracker/ index.php?func=detail&aid=783262&group_id=86916&ati d=581351 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=779839&group_id=5470 From noreply at sourceforge.net Mon Aug 4 21:33:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 4 23:38:31 2003 Subject: [Patches] [ python-Patches-677838 ] python-mode.el: make C-c - work correctly after C-c | Message-ID: Patches item #677838, was opened at 2003-01-30 17:11 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677838&group_id=5470 Category: Demos and tools Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Charles G Waldman (cgw) Assigned to: Skip Montanaro (montanaro) Summary: python-mode.el: make C-c - work correctly after C-c | Initial Comment: If you are using python-mode in [X]Emacs and do py-execute-region and get an exception, py-up-exception (C-c -) will go to the wrong line, because the line number reported by Python is only relative to the start of the region. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-08-04 22:33 Message: Logged In: YES user_id=44345 migrated to python-mode project. follow it here: https://sourceforge.net/tracker/ index.php?func=detail&aid=783260&group_id=86916&ati d=581351 ---------------------------------------------------------------------- Comment By: Charles G Waldman (cgw) Date: 2003-08-01 12:24 Message: Logged In: YES user_id=7151 updated patch ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-31 23:55 Message: Logged In: YES user_id=44345 Charles, Any chance you can generate your diff against the newest version of python-mode.el (something like 4.38)? I'm having trouble applying the patch you submitted originally, and my feeble manual attempts have so far not demonstrated that the patch (as I applied it) fixes the problem. Thx, Skip ---------------------------------------------------------------------- Comment By: Charles G Waldman (cgw) Date: 2003-01-31 10:37 Message: Logged In: YES user_id=7151 I tried uploading the patch again, and seem to have succeeded this time around. It's probably not fair to blane SF, as I think this was a case of pilot error. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-31 07:16 Message: Logged In: YES user_id=6656 There's no patch attached... I think SF is subliminally trying to push us into getting roundup ready to use. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677838&group_id=5470 From noreply at sourceforge.net Mon Aug 4 23:55:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 5 01:55:20 2003 Subject: [Patches] [ python-Patches-781126 ] fix gettext NullTranslation.add_fallback typo Message-ID: Patches item #781126, was opened at 2003-07-31 23:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=781126&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Bastian Kleineidam (calvin) Assigned to: Martin v. L?wis (loewis) Summary: fix gettext NullTranslation.add_fallback typo Initial Comment: replace a typo where {} is used instead of [] in the NullTranslation.add_fallback methoddesc TeX macro. Diff is against CVS rev 1.20 (Tue Jul 22 00:49:11 2003 UTC) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-08-05 07:55 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as 1.21 and 1.20.6.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=781126&group_id=5470 From noreply at sourceforge.net Tue Aug 5 00:28:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 5 02:28:27 2003 Subject: [Patches] [ python-Patches-783188 ] support for server side transactions in _ssl Message-ID: Patches item #783188, was opened at 2003-08-05 02:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=783188&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ilario Nardinocchi (illo) Assigned to: Nobody/Anonymous (nobody) Summary: support for server side transactions in _ssl Initial Comment: Added a parameter (server_mode, type int) to the newPySSLObject() function. If its value is non-zero, a server SSL transaction is attempted - by using SSL_accept() instead of SSL_connect(). Also, the parameter has been added to the PySocket_ssl() constructor function (it defaults to 0 for compatibility) and the ssl() documentation reflects the change. A new python function has been added (pending(), C function PySSL_SSLpending()), which calls SSL_pending() and returns its return value as a python integer. Added documentation for this one, too. The return value is the number of bytes still to be read from the input buffer, so that if it's greater than zero it is useless to call a select() in a nonblocking scenery. Trivial patch but it's the only way to code an SSL server without third-party stuff. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-05 08:28 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=783188&group_id=5470 From noreply at sourceforge.net Tue Aug 5 00:31:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 5 02:31:16 2003 Subject: [Patches] [ python-Patches-772696 ] Updated 2.2.3 .spec file. Message-ID: Patches item #772696, was opened at 2003-07-17 01:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=772696&group_id=5470 Category: Build Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Updated 2.2.3 .spec file. Initial Comment: I've updated the .spec file so that it deletes .cvsignore files after doing the build, so that they don't get included in the file list. This was due to a report by a user that .cvsignore files were causing problems with the RPM build. Sean ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-08-05 08:31 Message: Logged In: YES user_id=21627 Thanks, committed as 1.1.2.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=772696&group_id=5470 From noreply at sourceforge.net Tue Aug 5 00:31:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 5 02:31:58 2003 Subject: [Patches] [ python-Patches-768840 ] IRIX libmpc patch Message-ID: Patches item #768840, was opened at 2003-07-10 03:43 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768840&group_id=5470 Category: Build Group: Python 2.2.x >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Michael Pruett (mpruett) Assigned to: Nobody/Anonymous (nobody) Summary: IRIX libmpc patch Initial Comment: It is not necessary to link with -lmpc to get native threads on IRIX. I do not recall a time when this library was needed, but it was certainly prior to the release of IRIX 6.5 (in 1998). I propose removing references to this library, as is done in the following patch against Python 2.2.3. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-08-05 08:31 Message: Logged In: YES user_id=21627 Closing this for lack of feedback. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-10 23:14 Message: Logged In: YES user_id=21627 According to PEP 11, only Irix 4 support will get dropped, and only in Python 2.4. So Irix 5 is still supposed to work, and this patch is unacceptable unless there is confirmation that the patch does work on Irix 5. Of course, we can deprecate Irix 5 and mpc support now, i.e. give a warning in Python 2.4, and remove the code in Python 2.5. Then we would need to make sure whether all Irix 6 releases work with this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=768840&group_id=5470 From noreply at sourceforge.net Tue Aug 5 05:41:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 5 07:41:13 2003 Subject: [Patches] [ python-Patches-782810 ] typo in libfuture.tex Message-ID: Patches item #782810, was opened at 2003-08-04 08:16 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=782810&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 in libfuture.tex Initial Comment: "statement" was misspelled at one place in libfuture.tex. "Each statment" should be "Each statement". I've attached a patch file to fix this. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-05 06:41 Message: Logged In: YES user_id=80475 Applied to Doc/lib/libfuture.tex 1.2 Thanks for the patch! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=782810&group_id=5470 From noreply at sourceforge.net Tue Aug 5 10:02:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 5 12:03:26 2003 Subject: [Patches] [ python-Patches-543867 ] test for patch #543865 & others Message-ID: Patches item #543867, was opened at 2002-04-15 00:18 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=543867&group_id=5470 Category: Tests Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Hernan Martinez Foffani (hfoffani) Assigned to: Walter D?rwald (doerwalter) Summary: test for patch #543865 & others Initial Comment: Here are 3 patches for: - test_complex.py: . add several checks to force execution of unvisited parts of complexobject.c code. . add a test for complex floor division corresponding bug #543387 and fix #543865 - test_complex_future.py . add test for "future" true division. (actually this is not a patch but the hole file) - test_b1.py . add test for bug #543840 and it's fix at patch #543865 Regards, -Hernan ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2003-08-05 18:01 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_complex.py 1.13+1.14 and Lib/test/test_complex.py 1.12.6.1 ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2003-07-18 10:39 Message: Logged In: YES user_id=112690 thank you guys, for taking up these. sadly, i don't have linux available anymore. i must tell you that the patch was the result of a self- excercise to learn about CPython. don't be surprise if you don't see mayor improvements in code coverage percentages. at the time I was very happy if I saw just 1 new LOC on a branch tested: it meant that I understood Python's internals involved. sorry for the trouble. regards, -hernan ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-18 04:42 Message: Logged In: YES user_id=80475 Since __floordiv__ is deprecated for complex, it should be left out of the test. Otherwise, it is ready to load. Because they've already tagged the Py2.3 release candidate, am marking this as a Py2.4 addition. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-07-17 13:25 Message: Logged In: YES user_id=89016 OK here is a patch (diff4.txt) that merges test_complex_future.py into test_complex.py. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-15 23:11 Message: Logged In: YES user_id=80475 That's a much better plan. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-07-15 20:58 Message: Logged In: YES user_id=89016 test_complex.py is checked in as rev 1.12. test_complex_future.py looks good, although I don't exactly understand its purpose, as there are tests from true division and floor division in test_complex.py already. We could extend check_div() in test_complex.py to try both __truediv__ and __floordiv__. This would IMHO be better than the code duplication in test_complex_future.py ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-15 08:58 Message: Logged In: YES user_id=80475 Converted test_complex_future.py to unittest format. See attachment. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-15 08:16 Message: Logged In: YES user_id=80475 diff3.txt looks good and runs fine on my machine. I'm surprised that it did not increase code coverage. The comparisons of a ** 105 to itself should be commented as a whitebox test of a special case code path. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-07-14 23:08 Message: Logged In: YES user_id=89016 Reworking test_complex.py.diff3 into the attached diff3.txt I don't see any increase in code coverage for complexobject.c (it stays at 91.84%) except for the file writing test which brings the coverage up to 92.95%. The current tests in test_complex.py seem to cover most test cases from test_complex.py.diff3 (except that test_complex.py.diff3 uses ** and % and the current test_complex.py uses pow and __mod__). So I'd say we add the file writing test and drop the rest. I'll look at test_complex_future.py tomorrow. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-07-14 10:53 Message: Logged In: YES user_id=89016 OK, I'll see if I can look at the patches later today. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-14 09:49 Message: Logged In: YES user_id=80475 Walter, do you care to add these in unittest form? Also, since the tests are to validate bug fixes, they are appropriate to go into Py2.3. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-06 21:58 Message: Logged In: YES user_id=357491 The patch is now severely outdated since test_complex.py has been converted to PyUnit, but it might be pertinent to go through the patch and see if any tests are there that could be added. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-22 20:38 Message: Logged In: YES user_id=112690 Regarding "the error msg for complex pow says "remainder"; it shouldn't" you are correct, the exception string has a bad wording. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-22 20:31 Message: Logged In: YES user_id=112690 On: vereq(a ** 105, a ** 105) ... etc ... The c code in complexobject.c has special cases when the exponent is > 100, < than -100, and in-between. I didn't want to test for equality with constants to avoid messing up with floating point issues. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-04-22 20:21 Message: Logged In: YES user_id=31435 I'm not sure what lines like vereq(a ** 105, a ** 105) vereq(b ** -105, b ** -105) vereq(b ** -30, b ** -30) are trying to test. That we get the same answer when we do exactly the same thing twice? Note that complex % has been deprecated: no point adding a test for a deprecated feature. The error msg for complex pow says "remainder"; it shouldn't. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-22 20:09 Message: Logged In: YES user_id=6380 OK, I've deleted them for you. Who do you expect to review this? ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-22 20:02 Message: Logged In: YES user_id=112690 Yes to both questions. I'm withdrawing test_complex.py and test_b1.py. I can't delete them and I double checked that I were correctly logged in as hfoffani. SourceForge error: File Delete: ArtifactFile: Permission Denied ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-22 19:51 Message: Logged In: YES user_id=6380 I don't understand your comment. Are you withdrawing the files test_complex.py and test_b1.py? Have you uploaded these to separate patch issues? You should be able to delete them as the original submitter; ifthis doesn't work, let me know and I'll do it. ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-15 01:48 Message: Logged In: YES user_id=112690 Following Tim's advise to group together bug/fix/test, I'll leave this patch entry for improvements in the tests of complex numbers. Then the valid files are: 21173: test_complex_future.py and 21180: test_complex.diff3 ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-04-15 01:47 Message: Logged In: YES user_id=112690 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=543867&group_id=5470 From noreply at sourceforge.net Tue Aug 5 16:36:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 5 18:36:26 2003 Subject: [Patches] [ python-Patches-783807 ] Clarify PySequence_Setitem ref counting Message-ID: Patches item #783807, was opened at 2003-08-05 18:36 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=783807&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jay T Miller (jaytmiller) Assigned to: Nobody/Anonymous (nobody) Summary: Clarify PySequence_Setitem ref counting Initial Comment: The attached patch explicitly states that PySequence_SetItem *does not* steal a reference to the set value. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=783807&group_id=5470 From noreply at sourceforge.net Wed Aug 6 04:47:58 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 6 06:48:01 2003 Subject: [Patches] [ python-Patches-784089 ] A program to scan python files and list those require coding Message-ID: Patches item #784089, was opened at 2003-08-06 14: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=784089&group_id=5470 Category: Demos and tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Nobody/Anonymous (nobody) Summary: A program to scan python files and list those require coding Initial Comment: A program to scan python files (recursively) and list those that require coding directive (pseudocomment) because there non-ASCII characters in the file (including comments). The program treats files as python files if the extension is .py or there is "python" in the first line of the file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784089&group_id=5470 From noreply at sourceforge.net Wed Aug 6 04:50:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 6 06:50:25 2003 Subject: [Patches] [ python-Patches-784089 ] A program to scan python files and list those require coding Message-ID: Patches item #784089, was opened at 2003-08-06 14:47 Message generated for change (Settings changed) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784089&group_id=5470 Category: Demos and tools Group: Python 2.3 Status: Open Resolution: None >Priority: 3 Submitted By: Oleg Broytmann (phd) Assigned to: Nobody/Anonymous (nobody) Summary: A program to scan python files and list those require coding Initial Comment: A program to scan python files (recursively) and list those that require coding directive (pseudocomment) because there non-ASCII characters in the file (including comments). The program treats files as python files if the extension is .py or there is "python" in the first line of the file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784089&group_id=5470 From noreply at sourceforge.net Wed Aug 6 05:39:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 6 07:39:05 2003 Subject: [Patches] [ python-Patches-534304 ] PEP 263 Implementation Message-ID: Patches item #534304, was opened at 2002-03-24 13:52 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=534304&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: SUZUKI Hisao (suzuki_hisao) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 263 Implementation Initial Comment: This is a sample implementation of PEP 263 phase 2. This implementation behaves just as normal Python does if no other coding hints are given. Thus it does not hurt anyone who uses Python now. Note that it is strictly compatible with the PEP in that every program valid in the PEP is also valid in this implementation. This implementation also accepts files in UTF-16 with BOM. They are read as UTF-8 internally. Please try "utf16sample.py" included. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-08-06 12:39 Message: Logged In: YES user_id=6656 Compatibility with Emacs. ---------------------------------------------------------------------- Comment By: Jean Jordaan (neaj) Date: 2003-08-06 12:35 Message: Logged In: YES user_id=59821 This is a very sensible enhancement to Python. I would just like to ask a niggling question .. In the PEP, and below, everyone always talks of "encoding". This is also the terminology I'm familiar with from all over. So why on earth is the magic comment string just "coding", and not "encoding"? Perhaps the recognizing regexp can match both, prefering "encoding" and deprecating "coding"? My apologies if I'm missing something or repeating someone else .. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-08-04 18:42 Message: Logged In: YES user_id=21627 I have now implemented Neal's suggestions: I documented the processing of encodings, and changed a number of formatting problems. I have disabled the detection of UTF-16 BOMs, since they are not backed by the PEP. I have committed the changes as Makefile.pre.in 1.93 ref2.tex 1.38 Grammar 1.48 errcode.h 2.15 graminit.h 2.20 NEWS 1.451 parsetok.c 2.33 tokenizer.c 2.55 tokenizer.h 2.17 tokenizer_pgen.c 2.1 compile.c 2.250 graminit.c 2.34 pythonrun.c 2.165 The change to bltinmodule.c was there by mistake, so I have removed that change. SUZUKI Hisao, how would you like to be listed in Misc/ACKS? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-16 19:50 Message: Logged In: YES user_id=33168 I reviewed the patch. I don't like the usage of enc (and str to a lesser extent). In particular, there is an encoding field which is generally used. enc is used as a temporary from the callback. I don't have a solution, so perhaps it would be best to doc the purpose, usage and interaction of enc & str. There are some differences between the standard formatting and that used in the patch. return on same line as if among others. But these aren't too bad. Although I don't love the line do t++; while (...);. I didn't see any problems with the patch. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-05-09 14:42 Message: Logged In: YES user_id=21627 I have now updated this patch to the current CVS, and to be a complete PEP 263 implementation; it will issue warnings when it finds non-ASCII characters but no encoding declaration. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-04-26 20:41 Message: Logged In: YES user_id=21627 I've updated the PEP to describe how this approach should be used: Python 2.3 still should generate warnings only for using non-ASCII without declared encoding. I, too, hope that Mr Suzuki will update the patch to match the PEP, and for the CVS tree. As for supporting UTF-16: The stream reader currently has the .readline method disabled, since it won't work reliable for little-endian. So I think this should be an undocumented feature at the moment; I see no other technical problems with the approach taken in the patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-23 22:26 Message: Logged In: YES user_id=6380 I haven't looked at this very carefully, but it looks like it's well thought-out. Suzuki, can you prepare a patch relative to current CVS? I get several patch failures now. (Fortunately I have a checkout of 2.2 so I can still review and test the patch.) I don't know what the patch failures are about (haven't investigated) but imagine it might have to do with the PEP 279 (universal newlines) changes checked in by Jack Jansen, which replaces the tokenizer's fgets() calls with calls to Py_UniversalNewlineFgets(). Also, I can't read the README file (it's in Japanese :-). What is the expected output from the samples? For me, sjis_sample.py gives SyntaxError: 'unknown encoding' Martin, I'm unclear of how you intend to use this code. Do you intend to go straight to phase 2 of the PEP using this patch? Or do you intend to implement phase 1 of the PEP by modifying this code? Also, does the PEP describe the UTF-16 support as implemented by Suziki's patch? ---------------------------------------------------------------------- Comment By: SUZUKI Hisao (suzuki_hisao) Date: 2002-03-31 17:16 Message: Logged In: YES user_id=495142 Thank you for your review. Now 1. and 3. are fixed, and 2. is improved. (4. is not true.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-03-30 11:27 Message: Logged In: YES user_id=6656 Not going into 2.2.x. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-03-25 13:23 Message: Logged In: YES user_id=21627 The patch looks good, but needs a number of improvements. 1. I have problems building this code. When trying to build pgen, I get an error message of Parser/parsetok.c: In function `parsetok': Parser/parsetok.c:175: `encoding_decl' undeclared The problem here is that graminit.h hasn't been built yet, but parsetok refers to the symbol. 2. For some reason, error printing for incorrect encodings does not work - it appears that it prints the wrong line in the traceback. 3. The escape processing in Unicode literals is incorrect. For example, u"\" should denote only the non-ascii character. However, your implementation replaces the non-ASCII character with \u, resulting in \u, so the first backslash unescapes the second one. 4. I believe the escape processing in byte strings is also incorrect for encodings that allow \ in the second byte. Before processing escape characters, you convert back into the source encoding. If this produces a backslash character, escape processing will misinterpret that byte as an escape character. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=534304&group_id=5470 From noreply at sourceforge.net Wed Aug 6 05:35:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 6 07:48:47 2003 Subject: [Patches] [ python-Patches-534304 ] PEP 263 Implementation Message-ID: Patches item #534304, was opened at 2002-03-24 15:52 Message generated for change (Comment added) made by neaj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=534304&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: SUZUKI Hisao (suzuki_hisao) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 263 Implementation Initial Comment: This is a sample implementation of PEP 263 phase 2. This implementation behaves just as normal Python does if no other coding hints are given. Thus it does not hurt anyone who uses Python now. Note that it is strictly compatible with the PEP in that every program valid in the PEP is also valid in this implementation. This implementation also accepts files in UTF-16 with BOM. They are read as UTF-8 internally. Please try "utf16sample.py" included. ---------------------------------------------------------------------- Comment By: Jean Jordaan (neaj) Date: 2003-08-06 13:35 Message: Logged In: YES user_id=59821 This is a very sensible enhancement to Python. I would just like to ask a niggling question .. In the PEP, and below, everyone always talks of "encoding". This is also the terminology I'm familiar with from all over. So why on earth is the magic comment string just "coding", and not "encoding"? Perhaps the recognizing regexp can match both, prefering "encoding" and deprecating "coding"? My apologies if I'm missing something or repeating someone else .. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-08-04 19:42 Message: Logged In: YES user_id=21627 I have now implemented Neal's suggestions: I documented the processing of encodings, and changed a number of formatting problems. I have disabled the detection of UTF-16 BOMs, since they are not backed by the PEP. I have committed the changes as Makefile.pre.in 1.93 ref2.tex 1.38 Grammar 1.48 errcode.h 2.15 graminit.h 2.20 NEWS 1.451 parsetok.c 2.33 tokenizer.c 2.55 tokenizer.h 2.17 tokenizer_pgen.c 2.1 compile.c 2.250 graminit.c 2.34 pythonrun.c 2.165 The change to bltinmodule.c was there by mistake, so I have removed that change. SUZUKI Hisao, how would you like to be listed in Misc/ACKS? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-16 20:50 Message: Logged In: YES user_id=33168 I reviewed the patch. I don't like the usage of enc (and str to a lesser extent). In particular, there is an encoding field which is generally used. enc is used as a temporary from the callback. I don't have a solution, so perhaps it would be best to doc the purpose, usage and interaction of enc & str. There are some differences between the standard formatting and that used in the patch. return on same line as if among others. But these aren't too bad. Although I don't love the line do t++; while (...);. I didn't see any problems with the patch. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-05-09 15:42 Message: Logged In: YES user_id=21627 I have now updated this patch to the current CVS, and to be a complete PEP 263 implementation; it will issue warnings when it finds non-ASCII characters but no encoding declaration. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-04-26 21:41 Message: Logged In: YES user_id=21627 I've updated the PEP to describe how this approach should be used: Python 2.3 still should generate warnings only for using non-ASCII without declared encoding. I, too, hope that Mr Suzuki will update the patch to match the PEP, and for the CVS tree. As for supporting UTF-16: The stream reader currently has the .readline method disabled, since it won't work reliable for little-endian. So I think this should be an undocumented feature at the moment; I see no other technical problems with the approach taken in the patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-23 23:26 Message: Logged In: YES user_id=6380 I haven't looked at this very carefully, but it looks like it's well thought-out. Suzuki, can you prepare a patch relative to current CVS? I get several patch failures now. (Fortunately I have a checkout of 2.2 so I can still review and test the patch.) I don't know what the patch failures are about (haven't investigated) but imagine it might have to do with the PEP 279 (universal newlines) changes checked in by Jack Jansen, which replaces the tokenizer's fgets() calls with calls to Py_UniversalNewlineFgets(). Also, I can't read the README file (it's in Japanese :-). What is the expected output from the samples? For me, sjis_sample.py gives SyntaxError: 'unknown encoding' Martin, I'm unclear of how you intend to use this code. Do you intend to go straight to phase 2 of the PEP using this patch? Or do you intend to implement phase 1 of the PEP by modifying this code? Also, does the PEP describe the UTF-16 support as implemented by Suziki's patch? ---------------------------------------------------------------------- Comment By: SUZUKI Hisao (suzuki_hisao) Date: 2002-03-31 18:16 Message: Logged In: YES user_id=495142 Thank you for your review. Now 1. and 3. are fixed, and 2. is improved. (4. is not true.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-03-30 13:27 Message: Logged In: YES user_id=6656 Not going into 2.2.x. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-03-25 15:23 Message: Logged In: YES user_id=21627 The patch looks good, but needs a number of improvements. 1. I have problems building this code. When trying to build pgen, I get an error message of Parser/parsetok.c: In function `parsetok': Parser/parsetok.c:175: `encoding_decl' undeclared The problem here is that graminit.h hasn't been built yet, but parsetok refers to the symbol. 2. For some reason, error printing for incorrect encodings does not work - it appears that it prints the wrong line in the traceback. 3. The escape processing in Unicode literals is incorrect. For example, u"\" should denote only the non-ascii character. However, your implementation replaces the non-ASCII character with \u, resulting in \u, so the first backslash unescapes the second one. 4. I believe the escape processing in byte strings is also incorrect for encodings that allow \ in the second byte. Before processing escape characters, you convert back into the source encoding. If this produces a backslash character, escape processing will misinterpret that byte as an escape character. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=534304&group_id=5470 From noreply at sourceforge.net Wed Aug 6 06:36:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 6 08:36:24 2003 Subject: [Patches] [ python-Patches-784089 ] A program to scan python files and list those require coding Message-ID: Patches item #784089, was opened at 2003-08-06 12:47 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784089&group_id=5470 Category: Demos and tools Group: Python 2.3 Status: Open Resolution: None Priority: 3 Submitted By: Oleg Broytmann (phd) Assigned to: Nobody/Anonymous (nobody) Summary: A program to scan python files and list those require coding Initial Comment: A program to scan python files (recursively) and list those that require coding directive (pseudocomment) because there non-ASCII characters in the file (including comments). The program treats files as python files if the extension is .py or there is "python" in the first line of the file. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-06 14:36 Message: Logged In: YES user_id=38388 Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784089&group_id=5470 From noreply at sourceforge.net Wed Aug 6 09:25:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 6 11:25:07 2003 Subject: [Patches] [ python-Patches-784231 ] getopt_long_only() Message-ID: Patches item #784231, was opened at 2003-08-06 15: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=784231&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Souza (s3a) Assigned to: Nobody/Anonymous (nobody) Summary: getopt_long_only() Initial Comment: A getopt_long_only() implementation for the `getopt' module. Note that it has one slight difference from the glibc version, related to the `-W' behavior, in that it _really_ treats `-W foo' _as_ `--foo'; therefore, when `foo' is not a valid long option, this is an error --- rather than returning the option ('-W', 'foo') as though `W:' instead of `W;' had been specified. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784231&group_id=5470 From rosaxrichardii at yahoo.com Thu Aug 7 09:02:13 2003 From: rosaxrichardii at yahoo.com (Trade Secrets) Date: Thu Aug 7 08:04:18 2003 Subject: [Patches] Trade Secrets Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20030807/a0023811/attachment.htm From noreply at sourceforge.net Thu Aug 7 09:32:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 7 11:32:41 2003 Subject: [Patches] [ python-Patches-784825 ] fix obscure crash in descriptor handling Message-ID: Patches item #784825, was opened at 2003-08-07 16: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=784825&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: fix obscure crash in descriptor handling Initial Comment: Ages & ages back twouters pointed out a potential hole in PyObject_GenericGetAttr. I've come up with a testcase & a fix, attached to this report. Are there any other bits of code shaped like PyObject_GenericGetAttr? I've fixed type_getattro. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784825&group_id=5470 From noreply at sourceforge.net Thu Aug 7 21:11:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 7 23:11:15 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: 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: 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 Aug 8 17:44:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 8 19:44:37 2003 Subject: [Patches] [ python-Patches-785689 ] pydoc's usage should use basename Message-ID: Patches item #785689, was opened at 2003-08-08 23:44 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=785689&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc's usage should use basename Initial Comment: pydoc should output only the basename, not the full path. +++ Lib/pydoc.py 2003-08-09 01:40:58.000000000 +0200 @@ -2090,7 +2090,7 @@ print value except (getopt.error, BadUsage): - cmd = sys.argv[0] + cmd = os.path.basename(sys.argv[0]) print """pydoc - the Python documentation tool %s ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=785689&group_id=5470 From noreply at sourceforge.net Fri Aug 8 22:38:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 9 00:39:02 2003 Subject: [Patches] [ python-Patches-783807 ] Clarify PySequence_Setitem ref counting Message-ID: Patches item #783807, was opened at 2003-08-05 17:36 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=783807&group_id=5470 Category: Documentation >Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jay T Miller (jaytmiller) Assigned to: Nobody/Anonymous (nobody) Summary: Clarify PySequence_Setitem ref counting Initial Comment: The attached patch explicitly states that PySequence_SetItem *does not* steal a reference to the set value. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-08 23:38 Message: Logged In: YES user_id=80475 Applied as: Doc/api/abstract.tex 1.27 and 1.26.12.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=783807&group_id=5470 From noreply at sourceforge.net Fri Aug 8 23:04:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 9 01:04:49 2003 Subject: [Patches] [ python-Patches-747364 ] BaseHTTPServer doesn't need StringIO intermediary Message-ID: Patches item #747364, was opened at 2003-06-02 02:40 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=747364&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Raymond Hettinger (rhettinger) Summary: BaseHTTPServer doesn't need StringIO intermediary Initial Comment: This is Python2.3b1, from CVS I looked at the implementation of the BaseHTTPServer.py code where it does the actual parsing. I see that it has # Deal with pipelining bytes = "" while 1: line = self.rfile.readline() bytes = bytes + line if line == '\r\n' or line == '\n' or line == '': break # Examine the headers and look for a Connection directive hfile = cStringIO.StringIO(bytes) self.headers = self.MessageClass(hfile) The MessageClass is mimetools.Message, which uses rfc822.Message to parse the headers. The Message reads the input stream up to and including the end-of-header blank line, but no further, using while 1: ... line = self.fp.readline() ... elif self.islast(line): # Note! No pushback here! The delimiter line gets eaten break def islast(self, line): """Determine whether a line is a legal end of RFC 2822 headers. and checks for '\r\n' or '\n' so it seems the temporary copy into a StringIO isn't needed since the Message can deal with it correctly. Plus, Message takes a 'seekable' parameter which can turn off seeking on the input stream, and has for a long time (since well before Martin's "Deal with pipelining code"). The proof, as they say, is in the pudding. Thought I don't know why. Anyway, I replaced the "bytes ... " code and used self.rfile rather than the temporary StringIO hfile, as in self.headers = self.MessageClass(self.rfile) print "Does it work?", repr(self.rfile.readline()) (I added the print to make sure the data wasn't eaten) I tested it with the module's mainline self-test, and it seems to work just fine. Attached patch does the same, only without the debugging print statement. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-09 00:04 Message: Logged In: YES user_id=80475 Modified to also remove the import for cStringIO. Did not change seekable argument from 0 to False so that the style stayed consistent with mimetools.py and rfc822.py. Applied as: Lib/BaseHTTPServer.py 1.28 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-13 21:10 Message: Logged In: YES user_id=80475 Okay, will post patch after Py2.3 goes out. ---------------------------------------------------------------------- Comment By: Chris Lawrence (lordsutch) Date: 2003-07-13 17:17 Message: Logged In: YES user_id=6757 I honestly don't remember why I used the StringIO wrapper. It could have been that the seekable parameter was undocumented at the time, or added while I was evolving the patch locally, so I wasn't aware of it. (I'd probably change the parameter to False, since this is a 2.3+ patch, but that's a cosmetic issue.) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-13 05:06 Message: Logged In: YES user_id=21627 I agree this is a reasonable change, and I also agree that it comes too late for 2.3. I don't know what Chris Lawrence' rationale was to wrap the header in a StringIO; I'll ask him. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-12 20:05 Message: Logged In: YES user_id=80475 Martin, you added this code last year (ver 1.19) in response to www.python.org/sf/430706 . Was the += build from readline and the trip through CStringIO necessary? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-01 00:27 Message: Logged In: YES user_id=80475 "the proof is in the pudding" lost its clarity when it got shortened from "the proof of the pudding is in the eating" meaning that recipes are best judged by their results. The patch looks fine to me but it is too late in the development cycle to include in Py2.3. Marking as a Py2.4 idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=747364&group_id=5470 From noreply at sourceforge.net Sat Aug 9 00:05:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 9 02:05:11 2003 Subject: [Patches] [ python-Patches-785752 ] Documentation for platform module Message-ID: Patches item #785752, was opened at 2003-08-08 23:05 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=785752&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bjorn Pettersen (bpettersen) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation for platform module Initial Comment: This is my first time writing module documentation so be gentle . Let me know if I did something wrong and I'll fix and resubmit (compiling the docs sounded like dark magic, so I skipped that part ;-) -- bjorn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=785752&group_id=5470 From noreply at sourceforge.net Sat Aug 9 03:08:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 9 05:08:33 2003 Subject: [Patches] [ python-Patches-771998 ] Fix for LD_LIBRARY_PATH inheritance on SunOS when -shared Message-ID: Patches item #771998, was opened at 2003-07-16 02:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=771998&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: David Ascher (david_ascher) Assigned to: Martin v. L?wis (loewis) Summary: Fix for LD_LIBRARY_PATH inheritance on SunOS when -shared Initial Comment: The attached patch fixes a problem whereby building with --enable-shared fails if the user already has an LD_LIBRARY_PATH setting. The absence of {}'s can cause a failure to interpolate the existing values. Tested on Solaris 2.6, but "should" work equally well on the other affected platforms (Linux, HP-UX and OSF). Patch from Jeff Hobbs. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-08-09 11:08 Message: Logged In: YES user_id=21627 Committed as configure 1.418 configure.in 1.429 configure 1.416.4.1 configure.in 1.427.4.1 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-24 21:17 Message: Logged In: YES user_id=21627 I'll accept the patch for application after 2.3; for 2.3, it is too late. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2003-07-24 20:42 Message: Logged In: YES user_id=72656 I have LD_LIBRARY_PATH set to /usr/local/lib in my env. g++ is the C++ compiler, and requires libstdc++ in /usr/local/lib. Running the unpatched configure gives me: RUNSHARED= LD_LIBRARY_PATH=/export/home/jeffh/src/Python-2.3c1: and patched gives me: RUNSHARED= LD_LIBRARY_PATH=/export/home/jeffh/src/Python- 2.3c1:/usr/local/lib Note that the only difference is that it actually substituted the LD_LIBRARY_PATH from my env correctly the second time. I know that this seems contrary to the docs, but when I encountered this, I knew exactly what to look for in configure, because I have seen this before on the odd platform sh not behaving right. David was looking over my shoulder watching all the changes, so he can vouch that I'm not crazy on this one. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-24 20:22 Message: Logged In: YES user_id=21627 I disagree that --enable-shared should be the default. It is difficult to maintain, as finding shared libraries is always a PITA (in particular on Solaris). Its only real use is for embedding, in even in the case of embedding, it is possible to avoid using shared libraries. According to the sh(1) man page of Solaris: # The braces are required only when parameter # is followed by a letter, digit, or underscore that is # not to be interpreted as part of its name. Since the variable name is not followed by a letter, digit, or underscore in this case, the braces are not needed. Can you please report precisely what the problem was that you mention in the first sentence of your report? What was the specific setting of LD_LIBRARY_PATH, and how did you find out there was a failure in interpolation? ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2003-07-24 19:09 Message: Logged In: YES user_id=72656 It is correct that this is for --enable-shared and use of C++ compiler (if it isn't needed, why is that on by default?). But not that all the other solutions require extra effort as well, and it is a simple and correct fix (it is a pedantic shell construct). Without --enable-shared (which should be default IMHO) you cannot embed python, which is needed in my case for Mozilla/pyxpcom. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-24 07:46 Message: Logged In: YES user_id=21627 This is all not true: a) "you cannot build with gcc installed in the standard /usr/local area". This is not true. This report is about --enable-shared. You can certainly install Python without --enable-shared. b) "libstdc++ will not be found". This is not true. There are many ways to find libstdc++, on Solaris, that don't involve setting LD_LIBRARY_PATH: 1. Use crle(1) 2. Edit the gcc specs file, to add -R/usrt/local/lib to all linker invocations. 3. Set LD_RUN_PATH 4. Configure with --without-cxx. Then libstdc++ won't be needed in the first place. 5. Configure with BASECFLAGS=-R/usr/local/lib Each of these approaches is better than setting LD_LIBRARY_PATH, since it won't require the Python users to set LD_LIBRARY_PATH later. c) I still fail to see the need for this patch. It is not only Linux that does not need it, it is also unnecessary on Solaris. I can only try Solaris 9, but on that system, LD_LIBRARY_PATH is copied into the Makefile even without the patch. I cannot believe that Solaris 2.6 is so broken. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2003-07-24 01:05 Message: Logged In: YES user_id=72656 Unfortunate that the prio was lowered. The point is that this is not for Linux - you have to see beyond one unix platform. Without this patch, you cannot build with gcc installed in the standard /usr/local/ area. libstdc++ will not be found, as /usr/local/lib (where it gets default installed) is not on the standard lib search path. The issue is that configure is losing the user's LD_LIBRARY_PATH setting. This will likely not effect SunPro builders, as they won't need libstdc++. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-22 21:45 Message: Logged In: YES user_id=21627 I'm lowering the priority. --enable-shared is not release-critical in the first place, as you can always build Python without that. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-22 17:06 Message: Logged In: YES user_id=12800 This is the last unresolved priority >= 7 issue for Python 2.3. Martin, David, can you guys make a final decision about this and either lower the priority or close the bug report? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-19 02:43 Message: Logged In: YES user_id=21627 I fail to see the point of this patch. The curly braces should not have any effect, and indeed, I can't see any effect on Linux here. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-18 19:44 Message: Logged In: YES user_id=31392 This sounds like probably the right thing to me, but I don't have any expertise. At the least, the patch needs to be made against configure.in. If we can resolve this in the next 30 minutes, I'm okay with it. If not, let's wait. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=771998&group_id=5470 From noreply at sourceforge.net Sat Aug 9 03:17:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 9 05:20:58 2003 Subject: [Patches] [ python-Patches-785752 ] Documentation for platform module Message-ID: Patches item #785752, was opened at 2003-08-09 08:05 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=785752&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bjorn Pettersen (bpettersen) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation for platform module Initial Comment: This is my first time writing module documentation so be gentle . Let me know if I did something wrong and I'll fix and resubmit (compiling the docs sounded like dark magic, so I skipped that part ;-) -- bjorn ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-08-09 11:17 Message: Logged In: YES user_id=21627 Thanks for this document. It currently does not follow the grammatical conventions. Please use the imperative voice; quoting from PEP 257 It prescribes the function or method's effect as a command ("Do this", "Return that"), not as a description; e.g. don't write "Returns the pathname ...". In addition, please indicate where you suggest this documentation to go in the table-of-contents, preferably by means of a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=785752&group_id=5470 From noreply at sourceforge.net Sat Aug 9 04:04:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 9 06:04:37 2003 Subject: [Patches] [ python-Patches-567468 ] A different patch for python-mode vs gdb Message-ID: Patches item #567468, was opened at 2002-06-11 18:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=567468&group_id=5470 Category: Demos and tools Group: Python 2.3 >Status: Closed Resolution: Rejected Priority: 6 Submitted By: Jason Merrill (jason_merrill) Assigned to: Barry A. Warsaw (bwarsaw) Summary: A different patch for python-mode vs gdb Initial Comment: Patch 509975 fixes the conflict between gdb-mode and python-mode by checking whether the current process is a python process. My patch fixes it more simply, by only clearing the overlay arrow if we were the ones who set it. I'd be happy with either patch. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-08-09 12:04 Message: Logged In: YES user_id=21627 This patch is now tracked in the python-mode project, at http://sourceforge.net/tracker/index.php?func=detail&aid=785816&group_id=86916&atid=581351 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-16 19:30 Message: Logged In: YES user_id=12800 Hmm, it must work differently in emacs than in XEmacs (which is what I use). In a vanilla Emacs 21.2.1 I can't get the overlay arrow to work even without python-mode.el loaded, so I'll have to take your word for it. In XEmacs, I definitely do get two overlay arrows, one in the C buffer and one in the python-mode buffer. As I step through the python program, the C arrow stays nicely visible and highlighted. As I step through gdb though, the python overlay arrow disappears. Your patch makes no difference to me and I can't get overlay arrow working at all in Emacs, so I suppose the patch is benign. I'll reopen it but I'd like confirmation from some other Emacs user that this fixes the problem in that editor. Alternatively, maybe I should just apply it and worry about it if people complain. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-07-16 19:02 Message: Logged In: NO The problem my patch was intended to fix is that currently just loading python-mode.el (as happens by default under Red Hat 7.3) breaks gdb-mode. With my patch, it works fine. emacs only supports one overlay arrow at a time; if you hit 'next' in gdb, gdb-mode will set the overlay arrow, which means that it will no longer be set in the python buffer. This may not be ideal behavior, but it's a limitation of emacs, not a bug in my patch. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-16 18:53 Message: Logged In: YES user_id=12800 I've rejected 509975 because it doesn't play nice when you're pdb tracking from the shell (see comments in that patch). I'm not sure this patch works correctly either, but for a different reason: it doesn't actually work for me! If I add "import pdb; pdb.set_trace()" to a file and then execute the file from the shell buffer, I see the overlay arrow. If I then switch to a gdb debugging a C program and hit "next", the overlay arrow in the .py buffer disappears. This seems like a tricky problem and I don't have a good solution, but I think I have to reject this patch too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=567468&group_id=5470 From noreply at sourceforge.net Sat Aug 9 07:00:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 9 09:00:54 2003 Subject: [Patches] [ python-Patches-762963 ] timemodule.c: Python loses current timezone Message-ID: Patches item #762963, was opened at 2003-06-30 04:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762963&group_id=5470 Category: Modules Group: None Status: Open Resolution: Rejected Priority: 5 Submitted By: Doug Quale (quale) Assigned to: Martin v. L?wis (loewis) Summary: timemodule.c: Python loses current timezone Initial Comment: Python routines in timemodule.c sometimes force glibc to use GMT instead of the correct timezone. I think this is a longstanding bug, but I have only looked at Python 2.2 and 2.33b1. This bug has been reported before (510218) but it was misdiagnosed and closed. It also came up recently in on the python-list (http://aspn.activestate.com/ASPN/Mail/Message/python-list/1564384) where it was also misdiagnosed. Standard C and Python use a struct tm with 9 values. BSD influenced C libraries like glibc have an extra field (tm_gmtoff) that keeps the offset from UTC. BSD-style struct tm values know the correct timezone associated with the time, but Python and Standard C struct tm values don't so they can only assume the current timezone. Ideally Python would always treat stuct tm-style time tuples as being associated with the current timezone. Unfortunately in many cases Python forces glibc to use GMT rather than the current timezone. You can see the problem most graphically with the %z format in strftime(). In the transcript Python incorrectly gives the timezone offset as +0000 even though it gets the timezone name (CDT) correct: $ python2.3 Python 2.3b1+ (#2, Jun 4 2003, 03:03:32) [GCC 3.3 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> now = time.localtime() >>> print now (2003, 6, 29, 20, 3, 52, 6, 180, 1) >>> RFC822 = '%a, %d %b %Y %T %z' >>> print time.strftime(RFC822, now) Sun, 29 Jun 2003 20:03:52 +0000 >>> print time.strftime(RFC822) Sun, 29 Jun 2003 20:05:27 -0500 >>> print time.strftime('%Z', now) CDT The correct timezone is CDT and the correct offset is -0500. Notice that when time.strftime() computes the current time it it gets the correct timezone offset, but when the struct tm tuple is passed in it thinks the timezone offset is 0. (glibc does know that the correct timezone name is CDT even when passed a bad struct tm value, but that's not surprising since the timezone name is not stored in struct tm and it is not computed from timezone offset.) The problem is in the gettmargs() function in timemodule.c. When getmargs() parses a Python tm tuple it leaves the tm_gmtoff field zeroed. This specifically tells glibc that the timezone offset is 0, which is wrong for most people. (BSD libc may also be affected.) This problem does not occur when time_strfrtime() gets the current time itself since that codepath uses a struct tm value directly from the libc localtime(), leaving the tm_gmtoff field intact. Fortunately the fix is almost trivial. A call to mktime() will normalize the fields in the struct tm value, including the tm_gmtoff field. I conditionalized the patch only on HAVE_MKTIME. I'm pretty sure there's an autoconfigure test for tm_gmtoff and it would probably be better to use that. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-08-09 15:00 Message: Logged In: YES user_id=21627 The patch is wrong. It changes the behaviour of time.asctime(time.gmtime(time.time())) which it shouldn't do. The problem is real, though, and might need to be solved by exposing the tm_gmtoff field where available. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-12 01:52 Message: Logged In: YES user_id=80475 Martin, can you diagnose whether this should be closed, applied, or deferred? ---------------------------------------------------------------------- Comment By: Doug Quale (quale) Date: 2003-07-10 20:14 Message: Logged In: YES user_id=812266 The problem isn't in strftime. The problem is in gettmargs() in timemodule.c. Python assumes that broken down time tuples are in the local timezone. The gettmargs() routine in timemodule.c is bugged on GNU libc and possibly other BSD-inspired C libraries. gettmargs() is supposed to take a Python broken down time tuple and convert it to a C struct tm. The Python time tuple is assumed to be in the local time zone, so the struct tm should be in the local timezone also. In glibc, struct tm has timezone fields so each struct tm knows its own timezone. The gettmargs() routine never fills in these extra fields so it always creates a struct tm in GMT. The appropriate behavior would be to set tm_gmtoff to the local timezone offset. My patch fixes gettmargs() to create struct tm's in the local timezone for C libraries that have the tm_gmtoff field in struct tm. As to the docs issue, the Python docs say that other formats may be supported than the ones listed. In reality, strftime() is passed to the underlying C library so the format codes supported are whatever the C library supports. The doc statement "Additional directives may be supported on certain platforms, but only the ones listed here have a meaning standardized by ANSI C" is wrong, or at least not up to date. C99 specifies several strftime format codes that are not listed including %z. I think Tim Smith also mentions this in a Python list posting from earlier this year. In the Python time module, the docs say strftime('format') is the same as strftime('format', localtime()). This is simply broken right now on glibc as has been reported by more than one person: >>> strftime('%z') '-0500' >>> strftime('%z', localtime()) '+0000' This is wrong. Unsupported format specifiers do not have this effect, for example: >>> strftime('%L') '%L' >>> strftime('%L', localtime()) '%L' This behavior is correct. A final note on the patch: I should have looked closer at the timemodule.c source. It already uses the appropriate #ifdef in other places. Instead of #ifdef HAVE_MKTIME my patch should be conditionalized #ifdef HAVE_STRUCT_TM_TM_ZONE. It's kind of amusing to write up this long of a justification for what is essentially a 3 line patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-10 00:36 Message: Logged In: YES user_id=357491 So the problem is with the %z directive not reporting the proper timezone offset, correct? If you look at http://www.python.org/ dev/doc/devel/lib/module-time.html , though, you will notice that %T is not supported as a directive for strftime or strptime nor has it ever been supported. Same goes for %T although it works in your example. Since the docs do not say that these directives are supported I am closing this patch since it would require altering both strftime and stprtime to support %z on all platforms which this patch does not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762963&group_id=5470 From noreply at sourceforge.net Sat Aug 9 07:02:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 9 09:02:56 2003 Subject: [Patches] [ python-Patches-762963 ] timemodule.c: Python loses current timezone Message-ID: Patches item #762963, was opened at 2003-06-30 04:18 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762963&group_id=5470 Category: Modules Group: None Status: Open Resolution: Rejected Priority: 5 Submitted By: Doug Quale (quale) >Assigned to: Nobody/Anonymous (nobody) Summary: timemodule.c: Python loses current timezone Initial Comment: Python routines in timemodule.c sometimes force glibc to use GMT instead of the correct timezone. I think this is a longstanding bug, but I have only looked at Python 2.2 and 2.33b1. This bug has been reported before (510218) but it was misdiagnosed and closed. It also came up recently in on the python-list (http://aspn.activestate.com/ASPN/Mail/Message/python-list/1564384) where it was also misdiagnosed. Standard C and Python use a struct tm with 9 values. BSD influenced C libraries like glibc have an extra field (tm_gmtoff) that keeps the offset from UTC. BSD-style struct tm values know the correct timezone associated with the time, but Python and Standard C struct tm values don't so they can only assume the current timezone. Ideally Python would always treat stuct tm-style time tuples as being associated with the current timezone. Unfortunately in many cases Python forces glibc to use GMT rather than the current timezone. You can see the problem most graphically with the %z format in strftime(). In the transcript Python incorrectly gives the timezone offset as +0000 even though it gets the timezone name (CDT) correct: $ python2.3 Python 2.3b1+ (#2, Jun 4 2003, 03:03:32) [GCC 3.3 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> now = time.localtime() >>> print now (2003, 6, 29, 20, 3, 52, 6, 180, 1) >>> RFC822 = '%a, %d %b %Y %T %z' >>> print time.strftime(RFC822, now) Sun, 29 Jun 2003 20:03:52 +0000 >>> print time.strftime(RFC822) Sun, 29 Jun 2003 20:05:27 -0500 >>> print time.strftime('%Z', now) CDT The correct timezone is CDT and the correct offset is -0500. Notice that when time.strftime() computes the current time it it gets the correct timezone offset, but when the struct tm tuple is passed in it thinks the timezone offset is 0. (glibc does know that the correct timezone name is CDT even when passed a bad struct tm value, but that's not surprising since the timezone name is not stored in struct tm and it is not computed from timezone offset.) The problem is in the gettmargs() function in timemodule.c. When getmargs() parses a Python tm tuple it leaves the tm_gmtoff field zeroed. This specifically tells glibc that the timezone offset is 0, which is wrong for most people. (BSD libc may also be affected.) This problem does not occur when time_strfrtime() gets the current time itself since that codepath uses a struct tm value directly from the libc localtime(), leaving the tm_gmtoff field intact. Fortunately the fix is almost trivial. A call to mktime() will normalize the fields in the struct tm value, including the tm_gmtoff field. I conditionalized the patch only on HAVE_MKTIME. I'm pretty sure there's an autoconfigure test for tm_gmtoff and it would probably be better to use that. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-09 15:00 Message: Logged In: YES user_id=21627 The patch is wrong. It changes the behaviour of time.asctime(time.gmtime(time.time())) which it shouldn't do. The problem is real, though, and might need to be solved by exposing the tm_gmtoff field where available. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-12 01:52 Message: Logged In: YES user_id=80475 Martin, can you diagnose whether this should be closed, applied, or deferred? ---------------------------------------------------------------------- Comment By: Doug Quale (quale) Date: 2003-07-10 20:14 Message: Logged In: YES user_id=812266 The problem isn't in strftime. The problem is in gettmargs() in timemodule.c. Python assumes that broken down time tuples are in the local timezone. The gettmargs() routine in timemodule.c is bugged on GNU libc and possibly other BSD-inspired C libraries. gettmargs() is supposed to take a Python broken down time tuple and convert it to a C struct tm. The Python time tuple is assumed to be in the local time zone, so the struct tm should be in the local timezone also. In glibc, struct tm has timezone fields so each struct tm knows its own timezone. The gettmargs() routine never fills in these extra fields so it always creates a struct tm in GMT. The appropriate behavior would be to set tm_gmtoff to the local timezone offset. My patch fixes gettmargs() to create struct tm's in the local timezone for C libraries that have the tm_gmtoff field in struct tm. As to the docs issue, the Python docs say that other formats may be supported than the ones listed. In reality, strftime() is passed to the underlying C library so the format codes supported are whatever the C library supports. The doc statement "Additional directives may be supported on certain platforms, but only the ones listed here have a meaning standardized by ANSI C" is wrong, or at least not up to date. C99 specifies several strftime format codes that are not listed including %z. I think Tim Smith also mentions this in a Python list posting from earlier this year. In the Python time module, the docs say strftime('format') is the same as strftime('format', localtime()). This is simply broken right now on glibc as has been reported by more than one person: >>> strftime('%z') '-0500' >>> strftime('%z', localtime()) '+0000' This is wrong. Unsupported format specifiers do not have this effect, for example: >>> strftime('%L') '%L' >>> strftime('%L', localtime()) '%L' This behavior is correct. A final note on the patch: I should have looked closer at the timemodule.c source. It already uses the appropriate #ifdef in other places. Instead of #ifdef HAVE_MKTIME my patch should be conditionalized #ifdef HAVE_STRUCT_TM_TM_ZONE. It's kind of amusing to write up this long of a justification for what is essentially a 3 line patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-10 00:36 Message: Logged In: YES user_id=357491 So the problem is with the %z directive not reporting the proper timezone offset, correct? If you look at http://www.python.org/ dev/doc/devel/lib/module-time.html , though, you will notice that %T is not supported as a directive for strftime or strptime nor has it ever been supported. Same goes for %T although it works in your example. Since the docs do not say that these directives are supported I am closing this patch since it would require altering both strftime and stprtime to support %z on all platforms which this patch does not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762963&group_id=5470 From noreply at sourceforge.net Sat Aug 9 09:47:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 9 11:47:11 2003 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 12:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None >Status: Open 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: Walter D?rwald (doerwalter) Date: 2003-08-09 17: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 15: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 13: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 21: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 11: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 21: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 16: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-18 01: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 23: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 14: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 23: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 21: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 21: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 21: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 21: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 20: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 20: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 18: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 17: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 17: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 14: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 19: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 18:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 17: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 15: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-19 01: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-18 05: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-18 04: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-18 03: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-18 03: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-18 03: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-18 02: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-18 01: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 Sat Aug 9 11:16:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 9 13:16:52 2003 Subject: [Patches] [ python-Patches-762963 ] timemodule.c: Python loses current timezone Message-ID: Patches item #762963, was opened at 2003-06-30 02:18 Message generated for change (Comment added) made by quale You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762963&group_id=5470 Category: Modules Group: None Status: Open Resolution: Rejected Priority: 5 Submitted By: Doug Quale (quale) Assigned to: Nobody/Anonymous (nobody) Summary: timemodule.c: Python loses current timezone Initial Comment: Python routines in timemodule.c sometimes force glibc to use GMT instead of the correct timezone. I think this is a longstanding bug, but I have only looked at Python 2.2 and 2.33b1. This bug has been reported before (510218) but it was misdiagnosed and closed. It also came up recently in on the python-list (http://aspn.activestate.com/ASPN/Mail/Message/python-list/1564384) where it was also misdiagnosed. Standard C and Python use a struct tm with 9 values. BSD influenced C libraries like glibc have an extra field (tm_gmtoff) that keeps the offset from UTC. BSD-style struct tm values know the correct timezone associated with the time, but Python and Standard C struct tm values don't so they can only assume the current timezone. Ideally Python would always treat stuct tm-style time tuples as being associated with the current timezone. Unfortunately in many cases Python forces glibc to use GMT rather than the current timezone. You can see the problem most graphically with the %z format in strftime(). In the transcript Python incorrectly gives the timezone offset as +0000 even though it gets the timezone name (CDT) correct: $ python2.3 Python 2.3b1+ (#2, Jun 4 2003, 03:03:32) [GCC 3.3 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> now = time.localtime() >>> print now (2003, 6, 29, 20, 3, 52, 6, 180, 1) >>> RFC822 = '%a, %d %b %Y %T %z' >>> print time.strftime(RFC822, now) Sun, 29 Jun 2003 20:03:52 +0000 >>> print time.strftime(RFC822) Sun, 29 Jun 2003 20:05:27 -0500 >>> print time.strftime('%Z', now) CDT The correct timezone is CDT and the correct offset is -0500. Notice that when time.strftime() computes the current time it it gets the correct timezone offset, but when the struct tm tuple is passed in it thinks the timezone offset is 0. (glibc does know that the correct timezone name is CDT even when passed a bad struct tm value, but that's not surprising since the timezone name is not stored in struct tm and it is not computed from timezone offset.) The problem is in the gettmargs() function in timemodule.c. When getmargs() parses a Python tm tuple it leaves the tm_gmtoff field zeroed. This specifically tells glibc that the timezone offset is 0, which is wrong for most people. (BSD libc may also be affected.) This problem does not occur when time_strfrtime() gets the current time itself since that codepath uses a struct tm value directly from the libc localtime(), leaving the tm_gmtoff field intact. Fortunately the fix is almost trivial. A call to mktime() will normalize the fields in the struct tm value, including the tm_gmtoff field. I conditionalized the patch only on HAVE_MKTIME. I'm pretty sure there's an autoconfigure test for tm_gmtoff and it would probably be better to use that. ---------------------------------------------------------------------- >Comment By: Doug Quale (quale) Date: 2003-08-09 17:16 Message: Logged In: YES user_id=812266 Martin is right. The call to mktime() in my patch overwrites the tm_isdst field. This field is in the Python time tuple and is correctly set by the code immediately above. I put the call to mktime in the wrong place. Instead of going at the end of the routine it belongs immediately after the memset used to zero the structure. Sorry about this botch. I have attached a corrected patch. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-09 13:00 Message: Logged In: YES user_id=21627 The patch is wrong. It changes the behaviour of time.asctime(time.gmtime(time.time())) which it shouldn't do. The problem is real, though, and might need to be solved by exposing the tm_gmtoff field where available. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-11 23:52 Message: Logged In: YES user_id=80475 Martin, can you diagnose whether this should be closed, applied, or deferred? ---------------------------------------------------------------------- Comment By: Doug Quale (quale) Date: 2003-07-10 18:14 Message: Logged In: YES user_id=812266 The problem isn't in strftime. The problem is in gettmargs() in timemodule.c. Python assumes that broken down time tuples are in the local timezone. The gettmargs() routine in timemodule.c is bugged on GNU libc and possibly other BSD-inspired C libraries. gettmargs() is supposed to take a Python broken down time tuple and convert it to a C struct tm. The Python time tuple is assumed to be in the local time zone, so the struct tm should be in the local timezone also. In glibc, struct tm has timezone fields so each struct tm knows its own timezone. The gettmargs() routine never fills in these extra fields so it always creates a struct tm in GMT. The appropriate behavior would be to set tm_gmtoff to the local timezone offset. My patch fixes gettmargs() to create struct tm's in the local timezone for C libraries that have the tm_gmtoff field in struct tm. As to the docs issue, the Python docs say that other formats may be supported than the ones listed. In reality, strftime() is passed to the underlying C library so the format codes supported are whatever the C library supports. The doc statement "Additional directives may be supported on certain platforms, but only the ones listed here have a meaning standardized by ANSI C" is wrong, or at least not up to date. C99 specifies several strftime format codes that are not listed including %z. I think Tim Smith also mentions this in a Python list posting from earlier this year. In the Python time module, the docs say strftime('format') is the same as strftime('format', localtime()). This is simply broken right now on glibc as has been reported by more than one person: >>> strftime('%z') '-0500' >>> strftime('%z', localtime()) '+0000' This is wrong. Unsupported format specifiers do not have this effect, for example: >>> strftime('%L') '%L' >>> strftime('%L', localtime()) '%L' This behavior is correct. A final note on the patch: I should have looked closer at the timemodule.c source. It already uses the appropriate #ifdef in other places. Instead of #ifdef HAVE_MKTIME my patch should be conditionalized #ifdef HAVE_STRUCT_TM_TM_ZONE. It's kind of amusing to write up this long of a justification for what is essentially a 3 line patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 22:36 Message: Logged In: YES user_id=357491 So the problem is with the %z directive not reporting the proper timezone offset, correct? If you look at http://www.python.org/ dev/doc/devel/lib/module-time.html , though, you will notice that %T is not supported as a directive for strftime or strptime nor has it ever been supported. Same goes for %T although it works in your example. Since the docs do not say that these directives are supported I am closing this patch since it would require altering both strftime and stprtime to support %z on all platforms which this patch does not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762963&group_id=5470 From noreply at sourceforge.net Sun Aug 10 07:03:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 10 09:03:39 2003 Subject: [Patches] [ python-Patches-786237 ] os.path.exists should use os.access when possible Message-ID: Patches item #786237, was opened at 2003-08-10 06: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=786237&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.exists should use os.access when possible Initial Comment: Compared to os.access, os.stat is very slow (probably due constructing to the stat object it returns). Therefore, os.path.exists should use os.access instead, when possible. (posixpath, I guess ntpath too.) (I didn't include a patch for ntpath since I can't test it.) As a bonus, the code is cleaner too. :) examples: > touch file_that_exists > python2.3 timeit.py -s "from os.path import exists" "exists('file_that_exists')" 100000 loops, best of 3: 15.6 usec per loop > python2.3 timeit.py -s "from newposixpath import exists" "exists('file_that_exists')" 100000 loops, best of 3: 6.17 usec per loop > python2.3 timeit.py -s "from os.path import exists" "exists('file_that_does_not_exist')" 10000 loops, best of 3: 48.9 usec per loop > python2.3 timeit.py -s "from newposixpath import exists" "exists('file_that_does_not_exist')" 100000 loops, best of 3: 6.37 usec per loop ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=786237&group_id=5470 From noreply at sourceforge.net Sun Aug 10 07:04:37 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 10 09:04:41 2003 Subject: [Patches] [ python-Patches-786237 ] os.path.exists should use os.access when possible Message-ID: Patches item #786237, was opened at 2003-08-10 06:03 Message generated for change (Settings changed) made by donut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=786237&group_id=5470 >Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.exists should use os.access when possible Initial Comment: Compared to os.access, os.stat is very slow (probably due constructing to the stat object it returns). Therefore, os.path.exists should use os.access instead, when possible. (posixpath, I guess ntpath too.) (I didn't include a patch for ntpath since I can't test it.) As a bonus, the code is cleaner too. :) examples: > touch file_that_exists > python2.3 timeit.py -s "from os.path import exists" "exists('file_that_exists')" 100000 loops, best of 3: 15.6 usec per loop > python2.3 timeit.py -s "from newposixpath import exists" "exists('file_that_exists')" 100000 loops, best of 3: 6.17 usec per loop > python2.3 timeit.py -s "from os.path import exists" "exists('file_that_does_not_exist')" 10000 loops, best of 3: 48.9 usec per loop > python2.3 timeit.py -s "from newposixpath import exists" "exists('file_that_does_not_exist')" 100000 loops, best of 3: 6.37 usec per loop ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=786237&group_id=5470 From noreply at sourceforge.net Mon Aug 11 01:26:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 03:30:04 2003 Subject: [Patches] [ python-Patches-785752 ] Documentation for platform module Message-ID: Patches item #785752, was opened at 2003-08-08 23:05 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=785752&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bjorn Pettersen (bpettersen) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation for platform module Initial Comment: This is my first time writing module documentation so be gentle . Let me know if I did something wrong and I'll fix and resubmit (compiling the docs sounded like dark magic, so I skipped that part ;-) -- bjorn ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-08-11 00:26 Message: Logged In: YES user_id=357491 If this patch gets accepted, please close bug #726911. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-09 02:17 Message: Logged In: YES user_id=21627 Thanks for this document. It currently does not follow the grammatical conventions. Please use the imperative voice; quoting from PEP 257 It prescribes the function or method's effect as a command ("Do this", "Return that"), not as a description; e.g. don't write "Returns the pathname ...". In addition, please indicate where you suggest this documentation to go in the table-of-contents, preferably by means of a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=785752&group_id=5470 From noreply at sourceforge.net Mon Aug 11 03:47:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 05:47:47 2003 Subject: [Patches] [ python-Patches-786531 ] 'the the' typo Message-ID: Patches item #786531, was opened at 2003-08-11 18: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=786531&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: 'the the' typo Initial Comment: I've grepped tex files and found so many 'the the' typos. I hope this patch will help. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=786531&group_id=5470 From noreply at sourceforge.net Mon Aug 11 05:55:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 07:55:52 2003 Subject: [Patches] [ python-Patches-786591 ] test_largefile cleanup patch Message-ID: Patches item #786591, was opened at 2003-08-11 03: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=786591&group_id=5470 Category: Tests Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: test_largefile cleanup patch Initial Comment: test_largefile can leave its temp file open if one of many tests fail. On platforms (e.g., Cygwin) that are "particular" about open files, this will cause other regression tests that use the same temp file to fail: $ ./python.exe -E -tt Lib/test/regrtest.py -l test_largefile test_mmap test_mutants test_largefile test test_largefile failed -- got -1794967295L, but expected 2500000001L test_mmap test test_mmap crashed -- exceptions.IOError: [Errno 13] Permission denied: '@test' test_mutants test test_mutants crashed -- exceptions.IOError: [Errno 13] Permission denied: '@test' The attached patch solves this problem by adding missing "try/finally" blocks. Note that the "large" size of this patch is due to many white space changes -- otherwise, the patch is small. I tested this patch under Red Hat Linux 8.0 too. Is someone willing to eyeball this one before I check it in? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=786591&group_id=5470 From noreply at sourceforge.net Mon Aug 11 06:14:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 08:14:30 2003 Subject: [Patches] [ python-Patches-775777 ] Cygwin test_netrc open mode patch Message-ID: Patches item #775777, was opened at 2003-07-22 10:16 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=775777&group_id=5470 Category: Tests Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: Cygwin test_netrc open mode patch Initial Comment: Unconditionally opening the temp file in text mode causes this test to fail under Cygwin. The attached patch corrects this problem. I tested this patch under Red Hat Linux 8.0 too. Please feel free to defer this patch until after 2.3 is released. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-08-11 04:14 Message: Logged In: YES user_id=86216 Now that 2.3 is released, I will ask for forgiveness instead of permission. :,) Committed to head as: Lib/test/test_netrc.py 1.6 Committed to release23-maint as: Lib/test/test_netrc.py 1.5.14.1 I hope that I chose the right branch tag... ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-07-24 06:20 Message: Logged In: YES user_id=86216 Sorry to be a pest, but can I check this in? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=775777&group_id=5470 From noreply at sourceforge.net Mon Aug 11 11:38:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 13:38:53 2003 Subject: [Patches] [ python-Patches-784825 ] fix obscure crash in descriptor handling Message-ID: Patches item #784825, was opened at 2003-08-07 16:32 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784825&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: fix obscure crash in descriptor handling Initial Comment: Ages & ages back twouters pointed out a potential hole in PyObject_GenericGetAttr. I've come up with a testcase & a fix, attached to this report. Are there any other bits of code shaped like PyObject_GenericGetAttr? I've fixed type_getattro. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-08-11 18:38 Message: Logged In: YES user_id=6656 upload new patch that has a test that doesn't call gc.get_referrers on the integer 1 and thus create uncollectable cycles (or something like that, anyway). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784825&group_id=5470 From noreply at sourceforge.net Mon Aug 11 11:42:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 13:42:11 2003 Subject: [Patches] [ python-Patches-784825 ] fix obscure crash in descriptor handling Message-ID: Patches item #784825, was opened at 2003-08-07 16:32 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784825&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: fix obscure crash in descriptor handling Initial Comment: Ages & ages back twouters pointed out a potential hole in PyObject_GenericGetAttr. I've come up with a testcase & a fix, attached to this report. Are there any other bits of code shaped like PyObject_GenericGetAttr? I've fixed type_getattro. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-08-11 18:42 Message: Logged In: YES user_id=6656 trying to attach again, grr ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-11 18:38 Message: Logged In: YES user_id=6656 upload new patch that has a test that doesn't call gc.get_referrers on the integer 1 and thus create uncollectable cycles (or something like that, anyway). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784825&group_id=5470 From noreply at sourceforge.net Mon Aug 11 14:38:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 16:38:53 2003 Subject: [Patches] [ python-Patches-786531 ] 'the the' typo Message-ID: Patches item #786531, was opened at 2003-08-11 04:47 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=786531&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) >Assigned to: Raymond Hettinger (rhettinger) Summary: 'the the' typo Initial Comment: I've grepped tex files and found so many 'the the' typos. I hope this patch will help. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=786531&group_id=5470 From noreply at sourceforge.net Mon Aug 11 18:02:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 20:02:26 2003 Subject: [Patches] [ python-Patches-786531 ] 'the the' typo Message-ID: Patches item #786531, was opened at 2003-08-11 04:47 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=786531&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Raymond Hettinger (rhettinger) Summary: 'the the' typo Initial Comment: I've grepped tex files and found so many 'the the' typos. I hope this patch will help. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-11 19:02 Message: Logged In: YES user_id=80475 Thanks for the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=786531&group_id=5470 From noreply at sourceforge.net Mon Aug 11 18:26:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 20:26:21 2003 Subject: [Patches] [ python-Patches-786531 ] 'the the' typo Message-ID: Patches item #786531, was opened at 2003-08-11 05:47 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=786531&group_id=5470 Category: Documentation Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Raymond Hettinger (rhettinger) Summary: 'the the' typo Initial Comment: I've grepped tex files and found so many 'the the' typos. I hope this patch will help. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-11 20:26 Message: Logged In: YES user_id=33168 Raymond, it would be good if you could add a check into your texcheck script to look for duplicate words like this. I thought about trying to hack it, but never got around to it. Maybe add a TODO? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-11 20:02 Message: Logged In: YES user_id=80475 Thanks for the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=786531&group_id=5470 From noreply at sourceforge.net Mon Aug 11 18:36:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 20:36:57 2003 Subject: [Patches] [ python-Patches-784825 ] fix obscure crash in descriptor handling Message-ID: Patches item #784825, was opened at 2003-08-07 10:32 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784825&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: fix obscure crash in descriptor handling Initial Comment: Ages & ages back twouters pointed out a potential hole in PyObject_GenericGetAttr. I've come up with a testcase & a fix, attached to this report. Are there any other bits of code shaped like PyObject_GenericGetAttr? I've fixed type_getattro. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-11 19:36 Message: Logged In: YES user_id=80475 In typeobject.c, eliminate the else-block so that it is obvious that the incref always gets executed before the block ends. Also, the first XDECREF (on line 2022) needs to be repositioned (to later in the block) because, in MSVC++, the descrgetfunc declaration (two lines below) needs to be the first line in the code block. The final exit path (marked "give up") also need a DECREF. In object.c, the DECREF on line 1459 should be a XDECREF and the final exit path (running PyErr_Format) also needs a XDECREF. This is labelled as a Py2.4 patch but it should probably be backported also. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-11 12:42 Message: Logged In: YES user_id=6656 trying to attach again, grr ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-11 12:38 Message: Logged In: YES user_id=6656 upload new patch that has a test that doesn't call gc.get_referrers on the integer 1 and thus create uncollectable cycles (or something like that, anyway). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784825&group_id=5470 From noreply at sourceforge.net Tue Aug 12 00:45:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 12 02:45:24 2003 Subject: [Patches] [ python-Patches-787189 ] termios module on IRIX Message-ID: Patches item #787189, was opened at 2003-08-12 06:45 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=787189&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Poinot (poinot) Assigned to: Nobody/Anonymous (nobody) Summary: termios module on IRIX Initial Comment: The termios.c module includes sys/termios.h in which a CTRL macro is present, but not defined because of the pre-processing switches: #if (_NO_POSIX && _NO_XOPEN4) || _ABIAPI #define CTRL(c) ((c)&037) Then, the sys/ioctl.h is included (at least by termios.c module) and this uses CTRL() macro ! This looks like a problem on the IRIX side, they should be consistent with their own headers. The simplest way I found was to add into termios.c the definition of CTRL: #if defined(__sgi) #define CTRL(c) ((c)&037) #endif Has to be put *before* the #include in Modules/termios.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=787189&group_id=5470 From noreply at sourceforge.net Tue Aug 12 04:21:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 12 06:22:03 2003 Subject: [Patches] [ python-Patches-784825 ] fix obscure crash in descriptor handling Message-ID: Patches item #784825, was opened at 2003-08-07 16:32 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784825&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Raymond Hettinger (rhettinger) Summary: fix obscure crash in descriptor handling Initial Comment: Ages & ages back twouters pointed out a potential hole in PyObject_GenericGetAttr. I've come up with a testcase & a fix, attached to this report. Are there any other bits of code shaped like PyObject_GenericGetAttr? I've fixed type_getattro. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-08-12 11:21 Message: Logged In: YES user_id=6656 First two comments: thanks, I've uploaded a new version with these taken on board. > In object.c, the DECREF on line 1459 should be a XDECREF No. Look where f came from. > and the final exit path (running PyErr_Format) also needs a > XDECREF. I object to putting in Py_XDECREF(foo) when I know foo == NULL. Or am I missing something? (this same applies to the similar comment about typeobject.c). > This is labelled as a Py2.4 patch but it should probably be > backported also. Oh yes, this applies to 2.3 and almost surely 2.2, too. Back to you. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-12 01:36 Message: Logged In: YES user_id=80475 In typeobject.c, eliminate the else-block so that it is obvious that the incref always gets executed before the block ends. Also, the first XDECREF (on line 2022) needs to be repositioned (to later in the block) because, in MSVC++, the descrgetfunc declaration (two lines below) needs to be the first line in the code block. The final exit path (marked "give up") also need a DECREF. In object.c, the DECREF on line 1459 should be a XDECREF and the final exit path (running PyErr_Format) also needs a XDECREF. This is labelled as a Py2.4 patch but it should probably be backported also. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-11 18:42 Message: Logged In: YES user_id=6656 trying to attach again, grr ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-11 18:38 Message: Logged In: YES user_id=6656 upload new patch that has a test that doesn't call gc.get_referrers on the integer 1 and thus create uncollectable cycles (or something like that, anyway). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784825&group_id=5470 From noreply at sourceforge.net Tue Aug 12 21:31:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 12 23:31:39 2003 Subject: [Patches] [ python-Patches-787789 ] unittest.py: Custom TestRunners and --verbose Message-ID: Patches item #787789, was opened at 2003-08-12 22: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=787789&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthew F. Barnes (mfbarnes) Assigned to: Nobody/Anonymous (nobody) 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__. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=787789&group_id=5470 From noreply at sourceforge.net Wed Aug 13 03:40:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 05:40:37 2003 Subject: [Patches] [ python-Patches-787929 ] reflect the introduce of boolean type(libcfgparser.tex) Message-ID: Patches item #787929, was opened at 2003-08-13 18: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=787929&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: reflect the introduce of boolean type(libcfgparser.tex) Initial Comment: * getboolean return true/false true/false is not a boolean type. This should be "return True/False". * remove_option Now returns True/False instead of 1/0 as remove_section. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=787929&group_id=5470 From noreply at sourceforge.net Wed Aug 13 12:49:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 14:49:34 2003 Subject: [Patches] [ python-Patches-788249 ] explicitly provide a buffer in PyFile_SetBufSize() Message-ID: Patches item #788249, was opened at 2003-08-13 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=788249&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Gaul (gaul) Assigned to: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788249&group_id=5470 From noreply at sourceforge.net Wed Aug 13 14:00:37 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 16:00:45 2003 Subject: [Patches] [ python-Patches-739124 ] Add use_default_colors support to curses module. Message-ID: Patches item #739124, was opened at 2003-05-17 08:38 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=739124&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: J?rg Lehmann (joergl) >Assigned to: A.M. Kuchling (akuchling) Summary: Add use_default_colors support to curses module. Initial Comment: This trivial patch adds support for the use_default_colors function to the curses module, if supported by the (n)curses library. This functionality is needed, if one wants to use transparency in a ncurses application. Included is a corresponding patch for the curses test module and the curses module's documentation. It would be nice, if this patch could be included in Python2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=739124&group_id=5470 From noreply at sourceforge.net Wed Aug 13 16:53:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 18:54:06 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 14: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=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'). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788404&group_id=5470 From noreply at sourceforge.net Wed Aug 13 17:14:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 19:14:49 2003 Subject: [Patches] [ python-Patches-739124 ] Add use_default_colors support to curses module. Message-ID: Patches item #739124, was opened at 2003-05-17 08:38 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=739124&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: J?rg Lehmann (joergl) Assigned to: A.M. Kuchling (akuchling) Summary: Add use_default_colors support to curses module. Initial Comment: This trivial patch adds support for the use_default_colors function to the curses module, if supported by the (n)curses library. This functionality is needed, if one wants to use transparency in a ncurses application. Included is a corresponding patch for the curses test module and the curses module's documentation. It would be nice, if this patch could be included in Python2.3. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-08-13 19:14 Message: Logged In: YES user_id=11375 Checked in to the 2.4 CVS tree. One small change was required: the method was defined with METH_VARARGS, but because it takes no arguments, it should have used METH_NOARGS. Thanks for your contribution! I wish I'd known about this patch in time to check it into 2.3, but no one assigned it to me. Off to look for any other dangling curses patches... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=739124&group_id=5470 From noreply at sourceforge.net Wed Aug 13 17:15:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 19:15:46 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 (Settings changed) 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: Open 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: 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 Wed Aug 13 17:18:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 19:18:42 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 (Settings changed) 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=772077&group_id=5470 From noreply at sourceforge.net Wed Aug 13 17:19:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 19:19:54 2003 Subject: [Patches] [ python-Patches-721464 ] Remote debugging with pdb.py Message-ID: Patches item #721464, was opened at 2003-04-14 19:02 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=721464&group_id=5470 Category: Library (Lib) >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Laurent Pelecq (lpelecq) Assigned to: Nobody/Anonymous (nobody) Summary: Remote debugging with pdb.py Initial Comment: With this patch, instances of pdb.Pdb can read and write from arbitrary file objects. It is based on similar changes that have been made to cmd.py. It basically consists of replacing print statement with calls to self.stdout.write. So it is possible for example to control the debugger from another terminal to debug curses-based applications or CGI scripts. I can provide a basic client/server debugger. This patch has been tested on Mandrake Linux 9.1 with the current CVS version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-22 13:15 Message: Logged In: YES user_id=80475 I think this is a good idea. It is past the the time for being added to 2.3. Unassigning, but will come back to it for 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=721464&group_id=5470 From noreply at sourceforge.net Wed Aug 13 22:04:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 00:05:04 2003 Subject: [Patches] [ python-Patches-788509 ] Glossary Message-ID: Patches item #788509, was opened at 2003-08-13 23:04 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=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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788509&group_id=5470 From noreply at sourceforge.net Thu Aug 14 02:33:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 04:34:54 2003 Subject: [Patches] [ python-Patches-788509 ] Glossary Message-ID: Patches item #788509, was opened at 2003-08-14 04:04 Message generated for change (Comment added) made by duncanb 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: Duncan Booth (duncanb) Date: 2003-08-14 08: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 Thu Aug 14 07:29:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 09:31:00 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-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 Thu Aug 14 13:48:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 15:48:08 2003 Subject: [Patches] [ python-Patches-784825 ] fix obscure crash in descriptor handling Message-ID: Patches item #784825, was opened at 2003-08-07 10:32 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784825&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Raymond Hettinger (rhettinger) Summary: fix obscure crash in descriptor handling Initial Comment: Ages & ages back twouters pointed out a potential hole in PyObject_GenericGetAttr. I've come up with a testcase & a fix, attached to this report. Are there any other bits of code shaped like PyObject_GenericGetAttr? I've fixed type_getattro. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-14 14:48 Message: Logged In: YES user_id=80475 This code in the section is as clear as mud. After several tries, I was able to see why the XDECREF was not needed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-12 05:21 Message: Logged In: YES user_id=6656 First two comments: thanks, I've uploaded a new version with these taken on board. > In object.c, the DECREF on line 1459 should be a XDECREF No. Look where f came from. > and the final exit path (running PyErr_Format) also needs a > XDECREF. I object to putting in Py_XDECREF(foo) when I know foo == NULL. Or am I missing something? (this same applies to the similar comment about typeobject.c). > This is labelled as a Py2.4 patch but it should probably be > backported also. Oh yes, this applies to 2.3 and almost surely 2.2, too. Back to you. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-11 19:36 Message: Logged In: YES user_id=80475 In typeobject.c, eliminate the else-block so that it is obvious that the incref always gets executed before the block ends. Also, the first XDECREF (on line 2022) needs to be repositioned (to later in the block) because, in MSVC++, the descrgetfunc declaration (two lines below) needs to be the first line in the code block. The final exit path (marked "give up") also need a DECREF. In object.c, the DECREF on line 1459 should be a XDECREF and the final exit path (running PyErr_Format) also needs a XDECREF. This is labelled as a Py2.4 patch but it should probably be backported also. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-11 12:42 Message: Logged In: YES user_id=6656 trying to attach again, grr ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-11 12:38 Message: Logged In: YES user_id=6656 upload new patch that has a test that doesn't call gc.get_referrers on the integer 1 and thus create uncollectable cycles (or something like that, anyway). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784825&group_id=5470 From noreply at sourceforge.net Thu Aug 14 14:02:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 16:02:13 2003 Subject: [Patches] [ python-Patches-787929 ] reflect the introduce of boolean type(libcfgparser.tex) Message-ID: Patches item #787929, was opened at 2003-08-13 04:40 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=787929&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: reflect the introduce of boolean type(libcfgparser.tex) Initial Comment: * getboolean return true/false true/false is not a boolean type. This should be "return True/False". * remove_option Now returns True/False instead of 1/0 as remove_section. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-14 15:02 Message: Logged In: YES user_id=80475 Accepted with adjustments. I quoted the inputs to show that they are strings. See and Doc/lib/libcfgparser.tex 1.30 and 1.29.16.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=787929&group_id=5470 From noreply at sourceforge.net Thu Aug 14 14:03:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 16:03:36 2003 Subject: [Patches] [ python-Patches-787789 ] unittest.py: Custom TestRunners and --verbose Message-ID: Patches item #787789, was opened at 2003-08-12 22:31 Message generated for change (Settings changed) made by rhettinger 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: 5 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__. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=787789&group_id=5470 From noreply at sourceforge.net Thu Aug 14 14:03:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 16:04:05 2003 Subject: [Patches] [ python-Patches-784825 ] fix obscure crash in descriptor handling Message-ID: Patches item #784825, was opened at 2003-08-07 10:32 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784825&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Michael Hudson (mwh) Summary: fix obscure crash in descriptor handling Initial Comment: Ages & ages back twouters pointed out a potential hole in PyObject_GenericGetAttr. I've come up with a testcase & a fix, attached to this report. Are there any other bits of code shaped like PyObject_GenericGetAttr? I've fixed type_getattro. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-14 14:48 Message: Logged In: YES user_id=80475 This code in the section is as clear as mud. After several tries, I was able to see why the XDECREF was not needed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-12 05:21 Message: Logged In: YES user_id=6656 First two comments: thanks, I've uploaded a new version with these taken on board. > In object.c, the DECREF on line 1459 should be a XDECREF No. Look where f came from. > and the final exit path (running PyErr_Format) also needs a > XDECREF. I object to putting in Py_XDECREF(foo) when I know foo == NULL. Or am I missing something? (this same applies to the similar comment about typeobject.c). > This is labelled as a Py2.4 patch but it should probably be > backported also. Oh yes, this applies to 2.3 and almost surely 2.2, too. Back to you. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-11 19:36 Message: Logged In: YES user_id=80475 In typeobject.c, eliminate the else-block so that it is obvious that the incref always gets executed before the block ends. Also, the first XDECREF (on line 2022) needs to be repositioned (to later in the block) because, in MSVC++, the descrgetfunc declaration (two lines below) needs to be the first line in the code block. The final exit path (marked "give up") also need a DECREF. In object.c, the DECREF on line 1459 should be a XDECREF and the final exit path (running PyErr_Format) also needs a XDECREF. This is labelled as a Py2.4 patch but it should probably be backported also. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-11 12:42 Message: Logged In: YES user_id=6656 trying to attach again, grr ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-11 12:38 Message: Logged In: YES user_id=6656 upload new patch that has a test that doesn't call gc.get_referrers on the integer 1 and thus create uncollectable cycles (or something like that, anyway). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784825&group_id=5470 From noreply at sourceforge.net Thu Aug 14 21:18:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 23:22:05 2003 Subject: [Patches] [ python-Patches-785752 ] Documentation for platform module Message-ID: Patches item #785752, was opened at 2003-08-09 02:05 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=785752&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bjorn Pettersen (bpettersen) >Assigned to: M.-A. Lemburg (lemburg) Summary: Documentation for platform module Initial Comment: This is my first time writing module documentation so be gentle . Let me know if I did something wrong and I'll fix and resubmit (compiling the docs sounded like dark magic, so I skipped that part ;-) -- bjorn ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-08-14 23:18 Message: Logged In: YES user_id=3066 Marc-Andre, could you please review these docs? Thanks! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-11 03:26 Message: Logged In: YES user_id=357491 If this patch gets accepted, please close bug #726911. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-09 05:17 Message: Logged In: YES user_id=21627 Thanks for this document. It currently does not follow the grammatical conventions. Please use the imperative voice; quoting from PEP 257 It prescribes the function or method's effect as a command ("Do this", "Return that"), not as a description; e.g. don't write "Returns the pathname ...". In addition, please indicate where you suggest this documentation to go in the table-of-contents, preferably by means of a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=785752&group_id=5470 From noreply at sourceforge.net Thu Aug 14 22:33:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 15 00:33:12 2003 Subject: [Patches] [ python-Patches-784825 ] fix obscure crash in descriptor handling Message-ID: Patches item #784825, was opened at 2003-08-07 10:32 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784825&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: fix obscure crash in descriptor handling Initial Comment: Ages & ages back twouters pointed out a potential hole in PyObject_GenericGetAttr. I've come up with a testcase & a fix, attached to this report. Are there any other bits of code shaped like PyObject_GenericGetAttr? I've fixed type_getattro. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-14 23:33 Message: Logged In: YES user_id=80475 P.S. It's not your code that's unclear; rather, the whole function is a nest of interdependencies, cyclomatic complexities, and too much activity between setting a state and something that depends on the state. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-14 14:48 Message: Logged In: YES user_id=80475 This code in the section is as clear as mud. After several tries, I was able to see why the XDECREF was not needed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-12 05:21 Message: Logged In: YES user_id=6656 First two comments: thanks, I've uploaded a new version with these taken on board. > In object.c, the DECREF on line 1459 should be a XDECREF No. Look where f came from. > and the final exit path (running PyErr_Format) also needs a > XDECREF. I object to putting in Py_XDECREF(foo) when I know foo == NULL. Or am I missing something? (this same applies to the similar comment about typeobject.c). > This is labelled as a Py2.4 patch but it should probably be > backported also. Oh yes, this applies to 2.3 and almost surely 2.2, too. Back to you. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-11 19:36 Message: Logged In: YES user_id=80475 In typeobject.c, eliminate the else-block so that it is obvious that the incref always gets executed before the block ends. Also, the first XDECREF (on line 2022) needs to be repositioned (to later in the block) because, in MSVC++, the descrgetfunc declaration (two lines below) needs to be the first line in the code block. The final exit path (marked "give up") also need a DECREF. In object.c, the DECREF on line 1459 should be a XDECREF and the final exit path (running PyErr_Format) also needs a XDECREF. This is labelled as a Py2.4 patch but it should probably be backported also. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-11 12:42 Message: Logged In: YES user_id=6656 trying to attach again, grr ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-11 12:38 Message: Logged In: YES user_id=6656 upload new patch that has a test that doesn't call gc.get_referrers on the integer 1 and thus create uncollectable cycles (or something like that, anyway). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784825&group_id=5470 From noreply at sourceforge.net Fri Aug 15 07:10:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 15 09:10:57 2003 Subject: [Patches] [ python-Patches-784825 ] fix obscure crash in descriptor handling Message-ID: Patches item #784825, was opened at 2003-08-07 16:32 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784825&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: fix obscure crash in descriptor handling Initial Comment: Ages & ages back twouters pointed out a potential hole in PyObject_GenericGetAttr. I've come up with a testcase & a fix, attached to this report. Are there any other bits of code shaped like PyObject_GenericGetAttr? I've fixed type_getattro. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-08-15 14:10 Message: Logged In: YES user_id=6656 Thanks for spending the brain cells on this! Checked in as: Objects/object.c revision 2.210 Objects/typeobject.c revision 2.244 Lib/test/test_descr.py revision 1.198 A large part of the obscurity in PyObject_GenericGetAttr comes from the inlining of _PyType_Lookup & PyObject_GetDictPtr. I really hope that it's worth it... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-15 05:33 Message: Logged In: YES user_id=80475 P.S. It's not your code that's unclear; rather, the whole function is a nest of interdependencies, cyclomatic complexities, and too much activity between setting a state and something that depends on the state. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-14 20:48 Message: Logged In: YES user_id=80475 This code in the section is as clear as mud. After several tries, I was able to see why the XDECREF was not needed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-12 11:21 Message: Logged In: YES user_id=6656 First two comments: thanks, I've uploaded a new version with these taken on board. > In object.c, the DECREF on line 1459 should be a XDECREF No. Look where f came from. > and the final exit path (running PyErr_Format) also needs a > XDECREF. I object to putting in Py_XDECREF(foo) when I know foo == NULL. Or am I missing something? (this same applies to the similar comment about typeobject.c). > This is labelled as a Py2.4 patch but it should probably be > backported also. Oh yes, this applies to 2.3 and almost surely 2.2, too. Back to you. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-12 01:36 Message: Logged In: YES user_id=80475 In typeobject.c, eliminate the else-block so that it is obvious that the incref always gets executed before the block ends. Also, the first XDECREF (on line 2022) needs to be repositioned (to later in the block) because, in MSVC++, the descrgetfunc declaration (two lines below) needs to be the first line in the code block. The final exit path (marked "give up") also need a DECREF. In object.c, the DECREF on line 1459 should be a XDECREF and the final exit path (running PyErr_Format) also needs a XDECREF. This is labelled as a Py2.4 patch but it should probably be backported also. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-11 18:42 Message: Logged In: YES user_id=6656 trying to attach again, grr ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-11 18:38 Message: Logged In: YES user_id=6656 upload new patch that has a test that doesn't call gc.get_referrers on the integer 1 and thus create uncollectable cycles (or something like that, anyway). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784825&group_id=5470 From noreply at sourceforge.net Fri Aug 15 07:11:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 15 09:11:06 2003 Subject: [Patches] [ python-Patches-784825 ] fix obscure crash in descriptor handling Message-ID: Patches item #784825, was opened at 2003-08-07 16:32 Message generated for change (Settings changed) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784825&group_id=5470 Category: Core (C code) Group: Python 2.4 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: fix obscure crash in descriptor handling Initial Comment: Ages & ages back twouters pointed out a potential hole in PyObject_GenericGetAttr. I've come up with a testcase & a fix, attached to this report. Are there any other bits of code shaped like PyObject_GenericGetAttr? I've fixed type_getattro. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-15 14:10 Message: Logged In: YES user_id=6656 Thanks for spending the brain cells on this! Checked in as: Objects/object.c revision 2.210 Objects/typeobject.c revision 2.244 Lib/test/test_descr.py revision 1.198 A large part of the obscurity in PyObject_GenericGetAttr comes from the inlining of _PyType_Lookup & PyObject_GetDictPtr. I really hope that it's worth it... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-15 05:33 Message: Logged In: YES user_id=80475 P.S. It's not your code that's unclear; rather, the whole function is a nest of interdependencies, cyclomatic complexities, and too much activity between setting a state and something that depends on the state. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-14 20:48 Message: Logged In: YES user_id=80475 This code in the section is as clear as mud. After several tries, I was able to see why the XDECREF was not needed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-12 11:21 Message: Logged In: YES user_id=6656 First two comments: thanks, I've uploaded a new version with these taken on board. > In object.c, the DECREF on line 1459 should be a XDECREF No. Look where f came from. > and the final exit path (running PyErr_Format) also needs a > XDECREF. I object to putting in Py_XDECREF(foo) when I know foo == NULL. Or am I missing something? (this same applies to the similar comment about typeobject.c). > This is labelled as a Py2.4 patch but it should probably be > backported also. Oh yes, this applies to 2.3 and almost surely 2.2, too. Back to you. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-12 01:36 Message: Logged In: YES user_id=80475 In typeobject.c, eliminate the else-block so that it is obvious that the incref always gets executed before the block ends. Also, the first XDECREF (on line 2022) needs to be repositioned (to later in the block) because, in MSVC++, the descrgetfunc declaration (two lines below) needs to be the first line in the code block. The final exit path (marked "give up") also need a DECREF. In object.c, the DECREF on line 1459 should be a XDECREF and the final exit path (running PyErr_Format) also needs a XDECREF. This is labelled as a Py2.4 patch but it should probably be backported also. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-11 18:42 Message: Logged In: YES user_id=6656 trying to attach again, grr ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-11 18:38 Message: Logged In: YES user_id=6656 upload new patch that has a test that doesn't call gc.get_referrers on the integer 1 and thus create uncollectable cycles (or something like that, anyway). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784825&group_id=5470 From fqd at yahoo.com Sun Aug 17 00:55:55 2003 From: fqd at yahoo.com (Fqd) Date: Sat Aug 16 11:57:53 2003 Subject: [Patches] BackUp your DVDs to CDs in 1-2 In-Reply-To: <6EFJLK30K8JF09KJ@python.org> References: <6EFJLK30K8JF09KJ@python.org> Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20030816/18ee73c3/attachment.htm From noreply at sourceforge.net Sun Aug 17 01:19:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 17 03:19:14 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 17:19 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=790000&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Neil Hodgson (nyamatongwe) Assigned to: Nobody/Anonymous (nobody) Summary: Allow os.access to handle Unicode file name Initial Comment: Patch to fix bug 789995 and unit test for fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790000&group_id=5470 From noreply at sourceforge.net Sun Aug 17 15:54:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 17 17:54:14 2003 Subject: [Patches] [ python-Patches-762963 ] timemodule.c: Python loses current timezone Message-ID: Patches item #762963, was opened at 2003-06-29 21:18 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762963&group_id=5470 Category: Modules Group: None Status: Open Resolution: Rejected Priority: 5 Submitted By: Doug Quale (quale) >Assigned to: Martin v. L?wis (loewis) Summary: timemodule.c: Python loses current timezone Initial Comment: Python routines in timemodule.c sometimes force glibc to use GMT instead of the correct timezone. I think this is a longstanding bug, but I have only looked at Python 2.2 and 2.33b1. This bug has been reported before (510218) but it was misdiagnosed and closed. It also came up recently in on the python-list (http://aspn.activestate.com/ASPN/Mail/Message/python-list/1564384) where it was also misdiagnosed. Standard C and Python use a struct tm with 9 values. BSD influenced C libraries like glibc have an extra field (tm_gmtoff) that keeps the offset from UTC. BSD-style struct tm values know the correct timezone associated with the time, but Python and Standard C struct tm values don't so they can only assume the current timezone. Ideally Python would always treat stuct tm-style time tuples as being associated with the current timezone. Unfortunately in many cases Python forces glibc to use GMT rather than the current timezone. You can see the problem most graphically with the %z format in strftime(). In the transcript Python incorrectly gives the timezone offset as +0000 even though it gets the timezone name (CDT) correct: $ python2.3 Python 2.3b1+ (#2, Jun 4 2003, 03:03:32) [GCC 3.3 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> now = time.localtime() >>> print now (2003, 6, 29, 20, 3, 52, 6, 180, 1) >>> RFC822 = '%a, %d %b %Y %T %z' >>> print time.strftime(RFC822, now) Sun, 29 Jun 2003 20:03:52 +0000 >>> print time.strftime(RFC822) Sun, 29 Jun 2003 20:05:27 -0500 >>> print time.strftime('%Z', now) CDT The correct timezone is CDT and the correct offset is -0500. Notice that when time.strftime() computes the current time it it gets the correct timezone offset, but when the struct tm tuple is passed in it thinks the timezone offset is 0. (glibc does know that the correct timezone name is CDT even when passed a bad struct tm value, but that's not surprising since the timezone name is not stored in struct tm and it is not computed from timezone offset.) The problem is in the gettmargs() function in timemodule.c. When getmargs() parses a Python tm tuple it leaves the tm_gmtoff field zeroed. This specifically tells glibc that the timezone offset is 0, which is wrong for most people. (BSD libc may also be affected.) This problem does not occur when time_strfrtime() gets the current time itself since that codepath uses a struct tm value directly from the libc localtime(), leaving the tm_gmtoff field intact. Fortunately the fix is almost trivial. A call to mktime() will normalize the fields in the struct tm value, including the tm_gmtoff field. I conditionalized the patch only on HAVE_MKTIME. I'm pretty sure there's an autoconfigure test for tm_gmtoff and it would probably be better to use that. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-17 16:54 Message: Logged In: YES user_id=80475 Can you attach a unittest that fails before the patch and succeeds afterward? ---------------------------------------------------------------------- Comment By: Doug Quale (quale) Date: 2003-08-09 12:16 Message: Logged In: YES user_id=812266 Martin is right. The call to mktime() in my patch overwrites the tm_isdst field. This field is in the Python time tuple and is correctly set by the code immediately above. I put the call to mktime in the wrong place. Instead of going at the end of the routine it belongs immediately after the memset used to zero the structure. Sorry about this botch. I have attached a corrected patch. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-09 08:00 Message: Logged In: YES user_id=21627 The patch is wrong. It changes the behaviour of time.asctime(time.gmtime(time.time())) which it shouldn't do. The problem is real, though, and might need to be solved by exposing the tm_gmtoff field where available. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-11 18:52 Message: Logged In: YES user_id=80475 Martin, can you diagnose whether this should be closed, applied, or deferred? ---------------------------------------------------------------------- Comment By: Doug Quale (quale) Date: 2003-07-10 13:14 Message: Logged In: YES user_id=812266 The problem isn't in strftime. The problem is in gettmargs() in timemodule.c. Python assumes that broken down time tuples are in the local timezone. The gettmargs() routine in timemodule.c is bugged on GNU libc and possibly other BSD-inspired C libraries. gettmargs() is supposed to take a Python broken down time tuple and convert it to a C struct tm. The Python time tuple is assumed to be in the local time zone, so the struct tm should be in the local timezone also. In glibc, struct tm has timezone fields so each struct tm knows its own timezone. The gettmargs() routine never fills in these extra fields so it always creates a struct tm in GMT. The appropriate behavior would be to set tm_gmtoff to the local timezone offset. My patch fixes gettmargs() to create struct tm's in the local timezone for C libraries that have the tm_gmtoff field in struct tm. As to the docs issue, the Python docs say that other formats may be supported than the ones listed. In reality, strftime() is passed to the underlying C library so the format codes supported are whatever the C library supports. The doc statement "Additional directives may be supported on certain platforms, but only the ones listed here have a meaning standardized by ANSI C" is wrong, or at least not up to date. C99 specifies several strftime format codes that are not listed including %z. I think Tim Smith also mentions this in a Python list posting from earlier this year. In the Python time module, the docs say strftime('format') is the same as strftime('format', localtime()). This is simply broken right now on glibc as has been reported by more than one person: >>> strftime('%z') '-0500' >>> strftime('%z', localtime()) '+0000' This is wrong. Unsupported format specifiers do not have this effect, for example: >>> strftime('%L') '%L' >>> strftime('%L', localtime()) '%L' This behavior is correct. A final note on the patch: I should have looked closer at the timemodule.c source. It already uses the appropriate #ifdef in other places. Instead of #ifdef HAVE_MKTIME my patch should be conditionalized #ifdef HAVE_STRUCT_TM_TM_ZONE. It's kind of amusing to write up this long of a justification for what is essentially a 3 line patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 17:36 Message: Logged In: YES user_id=357491 So the problem is with the %z directive not reporting the proper timezone offset, correct? If you look at http://www.python.org/ dev/doc/devel/lib/module-time.html , though, you will notice that %T is not supported as a directive for strftime or strptime nor has it ever been supported. Same goes for %T although it works in your example. Since the docs do not say that these directives are supported I am closing this patch since it would require altering both strftime and stprtime to support %z on all platforms which this patch does not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762963&group_id=5470 From noreply at sourceforge.net Mon Aug 18 03:59:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 18 05:59:18 2003 Subject: [Patches] [ python-Patches-790443 ] add SafeConfigParser to __all__ Message-ID: Patches item #790443, was opened at 2003-08-18 18: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=790443&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: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790443&group_id=5470 From noreply at sourceforge.net Mon Aug 18 11:52:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 18 13:52:35 2003 Subject: [Patches] [ python-Patches-790710 ] breakpoint command lists in pdb Message-ID: Patches item #790710, was opened at 2003-08-18 17: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=790710&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gr?goire Dooms (dooms) Assigned to: Nobody/Anonymous (nobody) Summary: breakpoint command lists in pdb Initial Comment: This patch enables the user to define a list of commands associated to a breakpoint. Those commands are executed whenever the given breakpoint makes the program stop execution. The "commands [bpnumber]" command works like in gdb. This patch is against the CVS HEAD, it has been tested with python 2.3. The documentation is updated too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790710&group_id=5470 From noreply at sourceforge.net Mon Aug 18 11:54:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 18 13:54:24 2003 Subject: [Patches] [ python-Patches-790710 ] breakpoint command lists in pdb Message-ID: Patches item #790710, was opened at 2003-08-18 17:52 Message generated for change (Settings changed) made by dooms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790710&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gr?goire Dooms (dooms) >Assigned to: Guido van Rossum (gvanrossum) Summary: breakpoint command lists in pdb Initial Comment: This patch enables the user to define a list of commands associated to a breakpoint. Those commands are executed whenever the given breakpoint makes the program stop execution. The "commands [bpnumber]" command works like in gdb. This patch is against the CVS HEAD, it has been tested with python 2.3. The documentation is updated too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790710&group_id=5470 From noreply at sourceforge.net Tue Aug 19 05:19:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 19 08:05:41 2003 Subject: [Patches] [ python-Patches-791153 ] inconsistency with implementation(logging) Message-ID: Patches item #791153, was opened at 2003-08-19 20:19 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=791153&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: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=791153&group_id=5470 From chillininnit at yahoo.com Wed Aug 20 14:22:26 2003 From: chillininnit at yahoo.com (UniqueMethods) Date: Fri Aug 22 09:22:43 2003 Subject: [Patches] The Best Techniqes Available Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20030820/3b188351/attachment.htm From noreply at sourceforge.net Thu Aug 21 18:35:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 11:42:01 2003 Subject: [Patches] [ python-Patches-792869 ] Tidying error messages in compile.c Message-ID: Patches item #792869, was opened at 2003-08-21 18:35 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=792869&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven Taschuk (staschuk) Assigned to: Nobody/Anonymous (nobody) Summary: Tidying error messages in compile.c Initial Comment: A couple minor tweaks: (1) for clarity, rename the macro LOCAL_GLOBAL to PARAM_GLOBAL, since this error message is used only for parameters being declared global; (2) for consistency, use that macro instead of an inline string in the first pass. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=792869&group_id=5470 From noreply at sourceforge.net Thu Aug 21 10:57:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 11:43:28 2003 Subject: [Patches] [ python-Patches-762963 ] timemodule.c: Python loses current timezone Message-ID: Patches item #762963, was opened at 2003-06-30 02:18 Message generated for change (Comment added) made by quale You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762963&group_id=5470 Category: Modules Group: None Status: Open Resolution: Rejected Priority: 5 Submitted By: Doug Quale (quale) Assigned to: Martin v. L?wis (loewis) Summary: timemodule.c: Python loses current timezone Initial Comment: Python routines in timemodule.c sometimes force glibc to use GMT instead of the correct timezone. I think this is a longstanding bug, but I have only looked at Python 2.2 and 2.33b1. This bug has been reported before (510218) but it was misdiagnosed and closed. It also came up recently in on the python-list (http://aspn.activestate.com/ASPN/Mail/Message/python-list/1564384) where it was also misdiagnosed. Standard C and Python use a struct tm with 9 values. BSD influenced C libraries like glibc have an extra field (tm_gmtoff) that keeps the offset from UTC. BSD-style struct tm values know the correct timezone associated with the time, but Python and Standard C struct tm values don't so they can only assume the current timezone. Ideally Python would always treat stuct tm-style time tuples as being associated with the current timezone. Unfortunately in many cases Python forces glibc to use GMT rather than the current timezone. You can see the problem most graphically with the %z format in strftime(). In the transcript Python incorrectly gives the timezone offset as +0000 even though it gets the timezone name (CDT) correct: $ python2.3 Python 2.3b1+ (#2, Jun 4 2003, 03:03:32) [GCC 3.3 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> now = time.localtime() >>> print now (2003, 6, 29, 20, 3, 52, 6, 180, 1) >>> RFC822 = '%a, %d %b %Y %T %z' >>> print time.strftime(RFC822, now) Sun, 29 Jun 2003 20:03:52 +0000 >>> print time.strftime(RFC822) Sun, 29 Jun 2003 20:05:27 -0500 >>> print time.strftime('%Z', now) CDT The correct timezone is CDT and the correct offset is -0500. Notice that when time.strftime() computes the current time it it gets the correct timezone offset, but when the struct tm tuple is passed in it thinks the timezone offset is 0. (glibc does know that the correct timezone name is CDT even when passed a bad struct tm value, but that's not surprising since the timezone name is not stored in struct tm and it is not computed from timezone offset.) The problem is in the gettmargs() function in timemodule.c. When getmargs() parses a Python tm tuple it leaves the tm_gmtoff field zeroed. This specifically tells glibc that the timezone offset is 0, which is wrong for most people. (BSD libc may also be affected.) This problem does not occur when time_strfrtime() gets the current time itself since that codepath uses a struct tm value directly from the libc localtime(), leaving the tm_gmtoff field intact. Fortunately the fix is almost trivial. A call to mktime() will normalize the fields in the struct tm value, including the tm_gmtoff field. I conditionalized the patch only on HAVE_MKTIME. I'm pretty sure there's an autoconfigure test for tm_gmtoff and it would probably be better to use that. ---------------------------------------------------------------------- >Comment By: Doug Quale (quale) Date: 2003-08-21 16:57 Message: Logged In: YES user_id=812266 I have attached a little unittest with two tests showing the problem. I stole some code from Lib/test/test_time.py for the test that checks behavior in the US Eastern timezone. That test won't be run if tzset() isn't available, but this is OK since the only libc's that will show this problem are BSD-inspired and will have tzset(). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-17 21:54 Message: Logged In: YES user_id=80475 Can you attach a unittest that fails before the patch and succeeds afterward? ---------------------------------------------------------------------- Comment By: Doug Quale (quale) Date: 2003-08-09 17:16 Message: Logged In: YES user_id=812266 Martin is right. The call to mktime() in my patch overwrites the tm_isdst field. This field is in the Python time tuple and is correctly set by the code immediately above. I put the call to mktime in the wrong place. Instead of going at the end of the routine it belongs immediately after the memset used to zero the structure. Sorry about this botch. I have attached a corrected patch. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-09 13:00 Message: Logged In: YES user_id=21627 The patch is wrong. It changes the behaviour of time.asctime(time.gmtime(time.time())) which it shouldn't do. The problem is real, though, and might need to be solved by exposing the tm_gmtoff field where available. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-11 23:52 Message: Logged In: YES user_id=80475 Martin, can you diagnose whether this should be closed, applied, or deferred? ---------------------------------------------------------------------- Comment By: Doug Quale (quale) Date: 2003-07-10 18:14 Message: Logged In: YES user_id=812266 The problem isn't in strftime. The problem is in gettmargs() in timemodule.c. Python assumes that broken down time tuples are in the local timezone. The gettmargs() routine in timemodule.c is bugged on GNU libc and possibly other BSD-inspired C libraries. gettmargs() is supposed to take a Python broken down time tuple and convert it to a C struct tm. The Python time tuple is assumed to be in the local time zone, so the struct tm should be in the local timezone also. In glibc, struct tm has timezone fields so each struct tm knows its own timezone. The gettmargs() routine never fills in these extra fields so it always creates a struct tm in GMT. The appropriate behavior would be to set tm_gmtoff to the local timezone offset. My patch fixes gettmargs() to create struct tm's in the local timezone for C libraries that have the tm_gmtoff field in struct tm. As to the docs issue, the Python docs say that other formats may be supported than the ones listed. In reality, strftime() is passed to the underlying C library so the format codes supported are whatever the C library supports. The doc statement "Additional directives may be supported on certain platforms, but only the ones listed here have a meaning standardized by ANSI C" is wrong, or at least not up to date. C99 specifies several strftime format codes that are not listed including %z. I think Tim Smith also mentions this in a Python list posting from earlier this year. In the Python time module, the docs say strftime('format') is the same as strftime('format', localtime()). This is simply broken right now on glibc as has been reported by more than one person: >>> strftime('%z') '-0500' >>> strftime('%z', localtime()) '+0000' This is wrong. Unsupported format specifiers do not have this effect, for example: >>> strftime('%L') '%L' >>> strftime('%L', localtime()) '%L' This behavior is correct. A final note on the patch: I should have looked closer at the timemodule.c source. It already uses the appropriate #ifdef in other places. Instead of #ifdef HAVE_MKTIME my patch should be conditionalized #ifdef HAVE_STRUCT_TM_TM_ZONE. It's kind of amusing to write up this long of a justification for what is essentially a 3 line patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 22:36 Message: Logged In: YES user_id=357491 So the problem is with the %z directive not reporting the proper timezone offset, correct? If you look at http://www.python.org/ dev/doc/devel/lib/module-time.html , though, you will notice that %T is not supported as a directive for strftime or strptime nor has it ever been supported. Same goes for %T although it works in your example. Since the docs do not say that these directives are supported I am closing this patch since it would require altering both strftime and stprtime to support %z on all platforms which this patch does not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762963&group_id=5470 From noreply at sourceforge.net Wed Aug 20 23:47:37 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 11:47:22 2003 Subject: [Patches] [ python-Patches-792338 ] timetuple() returns a struct_time Message-ID: Patches item #792338, was opened at 2003-08-20 23: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=792338&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: 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.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=792338&group_id=5470 From noreply at sourceforge.net Wed Aug 20 23:40:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 11:47:39 2003 Subject: [Patches] [ python-Patches-792336 ] Missing 'if' in datetime module docs Message-ID: Patches item #792336, was opened at 2003-08-20 23: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=792336&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: Missing 'if' in datetime module docs Initial Comment: There's an 'if' missing. Not much else to say. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=792336&group_id=5470 From noreply at sourceforge.net Tue Aug 19 23:53:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 11:59:02 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 (Tracker Item Submitted) made by Item Submitter 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=791706&group_id=5470 From noreply at sourceforge.net Wed Aug 20 02:30:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 12:09:12 2003 Subject: [Patches] [ python-Patches-791776 ] factor out SMTPHandler.emit date handling Message-ID: Patches item #791776, was opened at 2003-08-20 00: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=791776&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Gaul (gaul) Assigned to: Nobody/Anonymous (nobody) Summary: factor out SMTPHandler.emit date handling Initial Comment: Change SMTPHandler.emit to use email.Utils.formatdate for date formatting. This changes the format from Wdy, DD Mon YYYY HH:MM:SS GMT to Wdy, DD Mon YYYY HH:MM:SS (+/-)DDDD which is the preferred format for email messages according to RFC 2822. This format is also accepted by the obsolete RFCs 822 and 1123, so there should be no compatibility problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=791776&group_id=5470 From noreply at sourceforge.net Fri Aug 22 04:10:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 17:32:49 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 (Tracker Item Submitted) made by Item Submitter 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793070&group_id=5470 From noreply at sourceforge.net Fri Aug 22 02:42:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 17:33:18 2003 Subject: [Patches] [ python-Patches-793021 ] implement htmllib.HTMLParser.reset Message-ID: Patches item #793021, was opened at 2003-08-22 00:42 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=793021&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Gaul (gaul) Assigned to: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793021&group_id=5470 From noreply at sourceforge.net Fri Aug 22 18:34:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 21:36:45 2003 Subject: [Patches] [ python-Patches-793559 ] clear SGMLParser.__starttag_text on reset() Message-ID: Patches item #793559, was opened at 2003-08-22 16:34 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=793559&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: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793559&group_id=5470 From noreply at sourceforge.net Fri Aug 22 18:15:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 23 02:16:20 2003 Subject: [Patches] [ python-Patches-793553 ] urllib SSL authentication docs are wrong Message-ID: Patches item #793553, was opened at 2003-08-23 01: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=793553&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib SSL authentication docs are wrong Initial Comment: urllib docs for URLOpener say: Additional keyword parameters, collected in x509, are used for authentication with the https: scheme. The keywords key_file and cert_file are supported; both are needed to actually retrieve a resource at an https: URL. They're not needed, and the certificate is never checked, because _ssl.c doesn't check it (which is documented in the socket.ssl docs). A doc patch is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793553&group_id=5470 From noreply at sourceforge.net Fri Aug 22 12:54:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 23 06:56:39 2003 Subject: [Patches] [ python-Patches-792336 ] Missing 'if' in datetime module docs Message-ID: Patches item #792336, was opened at 2003-08-20 23:40 Message generated for change (Comment added) made by staschuk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=792336&group_id=5470 Category: Documentation Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Steven Taschuk (staschuk) Assigned to: Nobody/Anonymous (nobody) Summary: Missing 'if' in datetime module docs Initial Comment: There's an 'if' missing. Not much else to say. ---------------------------------------------------------------------- >Comment By: Steven Taschuk (staschuk) Date: 2003-08-22 12:54 Message: Logged In: YES user_id=666873 Urk! Yes, I should have directed attention to the patch in my description. A lesson for next time. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-22 10:27 Message: Logged In: YES user_id=80475 Okay, I see the patch now and have applied it. Thanks. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-22 10:24 Message: Logged In: YES user_id=80475 You could point out the specific sentence in question. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=792336&group_id=5470 From noreply at sourceforge.net Fri Aug 22 10:24:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 23 08:31:36 2003 Subject: [Patches] [ python-Patches-792336 ] Missing 'if' in datetime module docs Message-ID: Patches item #792336, was opened at 2003-08-21 00:40 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=792336&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: Missing 'if' in datetime module docs Initial Comment: There's an 'if' missing. Not much else to say. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-22 11:24 Message: Logged In: YES user_id=80475 You could point out the specific sentence in question. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=792336&group_id=5470 From noreply at sourceforge.net Fri Aug 22 18:20:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 23 11:43:27 2003 Subject: [Patches] [ python-Patches-731153 ] redirect fails in urllib2 Message-ID: Patches item #731153, was opened at 2003-05-02 05:58 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731153&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Lewis (davidmlewis) Assigned to: Jeremy Hylton (jhylton) Summary: redirect fails in urllib2 Initial Comment: There were two simple errors in urllib2's redirection code. In two cases, req.method was being invoked when the author meant req.get_method. The second error was the failure to make the redirected URL available to the redirect handler; I passed it as a parameter, but it could have been added as another instance variable. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-08-23 01:20 Message: Logged In: YES user_id=261020 This was fixed some time ago, and should be closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731153&group_id=5470 From noreply at sourceforge.net Fri Aug 22 10:27:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 23 12:32:11 2003 Subject: [Patches] [ python-Patches-792336 ] Missing 'if' in datetime module docs Message-ID: Patches item #792336, was opened at 2003-08-21 00:40 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=792336&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Steven Taschuk (staschuk) Assigned to: Nobody/Anonymous (nobody) Summary: Missing 'if' in datetime module docs Initial Comment: There's an 'if' missing. Not much else to say. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-22 11:27 Message: Logged In: YES user_id=80475 Okay, I see the patch now and have applied it. Thanks. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-22 11:24 Message: Logged In: YES user_id=80475 You could point out the specific sentence in question. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=792336&group_id=5470 From noreply at sourceforge.net Sat Aug 23 11:43:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 24 21:23:16 2003 Subject: [Patches] [ python-Patches-731153 ] redirect fails in urllib2 Message-ID: Patches item #731153, was opened at 2003-05-02 06:58 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731153&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Lewis (davidmlewis) Assigned to: Jeremy Hylton (jhylton) Summary: redirect fails in urllib2 Initial Comment: There were two simple errors in urllib2's redirection code. In two cases, req.method was being invoked when the author meant req.get_method. The second error was the failure to make the redirected URL available to the redirect handler; I passed it as a parameter, but it could have been added as another instance variable. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-08-23 19:43 Message: Logged In: YES user_id=11105 Closing. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-08-23 02:20 Message: Logged In: YES user_id=261020 This was fixed some time ago, and should be closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731153&group_id=5470 From noreply at sourceforge.net Sun Aug 24 18:15:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 24 21:28:51 2003 Subject: [Patches] [ python-Patches-794400 ] startup file compiler flags Message-ID: Patches item #794400, was opened at 2003-08-24 17: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=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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=794400&group_id=5470 From noreply at sourceforge.net Mon Aug 25 12:16:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 25 14:16:09 2003 Subject: [Patches] [ python-Patches-794826 ] __file__ attribute missing from dynamicly loaded module Message-ID: Patches item #794826, was opened at 2003-08-25 14:16 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=794826&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Shack Toms (shacktoms) Assigned to: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=794826&group_id=5470 From noreply at sourceforge.net Tue Aug 26 06:02:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 26 08:04:38 2003 Subject: [Patches] [ python-Patches-786591 ] test_largefile cleanup patch Message-ID: Patches item #786591, was opened at 2003-08-11 03:55 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=786591&group_id=5470 Category: Tests Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: test_largefile cleanup patch Initial Comment: test_largefile can leave its temp file open if one of many tests fail. On platforms (e.g., Cygwin) that are "particular" about open files, this will cause other regression tests that use the same temp file to fail: $ ./python.exe -E -tt Lib/test/regrtest.py -l test_largefile test_mmap test_mutants test_largefile test test_largefile failed -- got -1794967295L, but expected 2500000001L test_mmap test test_mmap crashed -- exceptions.IOError: [Errno 13] Permission denied: '@test' test_mutants test test_mutants crashed -- exceptions.IOError: [Errno 13] Permission denied: '@test' The attached patch solves this problem by adding missing "try/finally" blocks. Note that the "large" size of this patch is due to many white space changes -- otherwise, the patch is small. I tested this patch under Red Hat Linux 8.0 too. Is someone willing to eyeball this one before I check it in? Thanks. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-08-26 04:02 Message: Logged In: YES user_id=86216 I guess that the eyeballs didn't find anything or weren't looking... :,) Committed on HEAD as Lib/test/test_largefile.py 1.17 and release23-maint as Lib/test/test_largefile.py 1.16.16.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=786591&group_id=5470 From noreply at sourceforge.net Tue Aug 26 12:08:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 26 14:09:10 2003 Subject: [Patches] [ python-Patches-795531 ] license inconsistency Message-ID: Patches item #795531, was opened at 2003-08-26 18:08 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=795531&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Gough (briangough) Assigned to: Nobody/Anonymous (nobody) Summary: license inconsistency Initial Comment: there is a discrepancy between the format of the dates in copyright.tex and in license.tex (2001,2002,2003 vs 2001-2003), which fails on a strict interpretation of the license ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=795531&group_id=5470 From noreply at sourceforge.net Tue Aug 26 23:13:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 27 01:13:55 2003 Subject: [Patches] [ python-Patches-756253 ] itertools roundrobin() and window() Message-ID: Patches item #756253, was opened at 2003-06-17 16:35 Message generated for change (Comment added) made by rhettinger 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() and window() 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: Raymond Hettinger (rhettinger) Date: 2003-08-27 00: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 00:12 Message: Logged In: YES user_id=80475 Great. I look forward to it. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2003-06-27 13: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 13: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 15: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 Tue Aug 26 23:15:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 27 01:15:36 2003 Subject: [Patches] [ python-Patches-727789 ] Editing of __str__ and __repr__ docs Message-ID: Patches item #727789, was opened at 2003-04-25 17:25 Message generated for change (Comment added) made by rhettinger 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: Open 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: Raymond Hettinger (rhettinger) Date: 2003-08-27 00: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 20: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 19: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 19: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 23: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 Wed Aug 27 02:10:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 27 04:10:13 2003 Subject: [Patches] [ python-Patches-795859 ] typo(PEP 236) Message-ID: Patches item #795859, was opened at 2003-08-27 17:10 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=795859&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: typo(PEP 236) Initial Comment: In PEP 236, the word ``keep'' is duplicated. for people who keep keep current with the latest release in a timely This should be for people who keep current with the latest release in a timely ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=795859&group_id=5470 From noreply at sourceforge.net Wed Aug 27 06:48:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 27 08:48:36 2003 Subject: [Patches] [ python-Patches-795947 ] Partial implementation of generator comprehensions Message-ID: Patches item #795947, was opened at 2003-08-27 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=795947&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Nobody/Anonymous (nobody) Summary: Partial implementation of generator comprehensions Initial Comment: Hello. Recently, Generator Comprehensions were mentioned again on python-list. I have written an implementation for the compiler module. To try it out, however, you must be able to rebuild Python from source, because it also requires a change to Grammar. 1. Edit Python-2.3/Grammar/Grammar and add an alternative to the "listmaker" production: -listmaker: test ( list_for | (',' test)* [','] ) +listmaker: test ( list_for | (',' test)* [','] ) | 'yield' test list_for 1.5. Now [yield None for x in []] parses, but crashes the written-in-C compiler: >>> [yield None for x in []] SystemError: com_node: unexpected node type 2. Apply the patch below to Lib/compiler 3. Use compiler.compile to compile code with generator comprehensions: from compiler import compile import dis code = compile(""" def f(): gg = [yield (x,y) for x in range(10) for y in range(10) if y > x] print gg, type(gg), list(gg) """, "", "exec") exec code dis.dis(f.func_code.co_consts[1]) f() 4. It's possible to write code so that __import__ uses compiler.compile instead of the written-in-C compiler, but I don't have this code handy. Also, a test suite is needed, and presumably a written-in-C implementation as well. (option 2: make the compiler.compile interface the standard compiler, and let the builtin compiler support a Python subset sufficient to bootstrap the written-in-python compiler, or arrange to ship .pyc of the compiler package and completely get rid of the written-in-C compiler) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=795947&group_id=5470 From noreply at sourceforge.net Wed Aug 27 07:58:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 27 10:02:00 2003 Subject: [Patches] [ python-Patches-750542 ] Let pprint.py use issubclass instead of is for type checking Message-ID: Patches item #750542, was opened at 2003-06-07 09:11 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750542&group_id=5470 Category: Library (Lib) >Group: Python 2.4 Status: Open Resolution: Rejected Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Let pprint.py use issubclass instead of is for type checking Initial Comment: Hi, subclasses of dict, list, tuple etc. should be pretty-printed according to the same rules as dict, list and tuple themselves. Because of that, this patch changes pprint.py so that rather than checking types using 'typ is list', pprint checks types using 'issubclass(typ, list)'. Gerrit Holl Patched against latest CVS ( 07/06/2003 13:11:24 UTC) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-06-08 19:06 Message: Logged In: YES user_id=21627 Assigning to Fred. ---------------------------------------------------------------------- Comment By: Gerrit Holl (gerrit) Date: 2003-06-08 16:06 Message: Logged In: YES user_id=13298 I have changed the patch. Instead of replacing 'typ is list' with 'issubclass(typ, list)', it is now replaced with 'issubclass(typ, list) and typ.__repr__ is typ.__list__'. This way, classes overriding __repr__ keep the current behaviour and classes that don't get the new behaviour. See also the thread on python-dev. BTW, I also expanded 2 of the 3 assert statements, so they explain what's wrong is somethings wrong. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-06-07 16:49 Message: Logged In: YES user_id=21627 I have reverted the patch on Fred's request. The patch does not support an overridden __repr__ implementation, and thus has to be rejected. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-06-07 16:31 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as pprint.py 1.25. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-06-07 16:30 Message: Logged In: YES user_id=3066 >From python-dev: http://mail.python.org/pipermail/python-dev/2003-June/036008.html Hmm; this patch was never assigned to me, so I was unaware that anyone thought there was a problem with this. I specifically considered making changes like these when subclassing built-in types became possible, but decided against it since it didn't appear reasonable to assume that __repr__() hadn't been redefined. I'm sure it's possible to check, but to do so cleanly and efficiently seems like a huge change to the module for little value. I think the patch, as it stands, should be reverted. If another patch appears that addresses the issue of overridden __repr__() methods, it should be considered again. -1 for the patch as applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750542&group_id=5470 From noreply at sourceforge.net Thu Aug 28 10:34:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 28 12:34:42 2003 Subject: [Patches] [ python-Patches-796772 ] CGIHTTPServer fix Message-ID: Patches item #796772, was opened at 2003-08-28 12:34 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=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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=796772&group_id=5470 From noreply at sourceforge.net Thu Aug 28 12:17:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 28 14:17:33 2003 Subject: [Patches] [ python-Patches-784231 ] getopt_long_only() Message-ID: Patches item #784231, was opened at 2003-08-06 17:25 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784231&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Souza (s3a) Assigned to: Nobody/Anonymous (nobody) Summary: getopt_long_only() Initial Comment: A getopt_long_only() implementation for the `getopt' module. Note that it has one slight difference from the glibc version, related to the `-W' behavior, in that it _really_ treats `-W foo' _as_ `--foo'; therefore, when `foo' is not a valid long option, this is an error --- rather than returning the option ('-W', 'foo') as though `W:' instead of `W;' had been specified. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2003-08-28 20:17 Message: Logged In: YES user_id=469548 I'm not sure we want to support this: our new option-parsing library optparse rejects this behavior (see http://python.org/doc/current/lib/optparse-terminology.html), and our gnu_getopt wasn't intended to work exactly like gnu_getopt (see http://python.org/sf/473512). On the other hand, your patch seems to work well, although you should add tests and a documentation patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784231&group_id=5470 From noreply at sourceforge.net Thu Aug 28 13:46:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 28 15:46:29 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 (Tracker Item Submitted) made by Item Submitter 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=796908&group_id=5470 From noreply at sourceforge.net Thu Aug 28 14:14:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 28 16:14:49 2003 Subject: [Patches] [ python-Patches-796919 ] Windows installer changes for 2.3.1 Message-ID: Patches item #796919, was opened at 2003-08-28 22: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=796919&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: Windows installer changes for 2.3.1 Initial Comment: Temporary url for the installer is http://starship.python.net/crew/theller/python-2.3.1-beta1.exe Remarks: Only .pyc files, no .pyo are compiled by the installer. This is the default, can be switched off in the "advanced options" installation dialog. In the selecte components dialog, 'Python HTML docs' should be renamed to 'Python HTMLHelp docs'. At the interactive prompt, 'help("BOOLEAN")' prints this: Python 2.3+ (#46, Aug 28 2003, 17:42:54) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> help("BOOLEAN") Sorry, topic and keyword documentation is not available because the Python HTML documentation files could not be found. If you have installed them, please set the environment variable PYTHONDOCS to indicate their location. >>> I only tested Windows XP Pro, admin install (default path, and path containing spaces). On Windows XP Pro, after installing to 'c:\path with spaces', everything seems to work, including IDLE (at least it starts, and finds to chm file). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=796919&group_id=5470 From noreply at sourceforge.net Thu Aug 28 14:19:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 28 16:19:16 2003 Subject: [Patches] [ python-Patches-796919 ] Windows installer changes for 2.3.1 Message-ID: Patches item #796919, was opened at 2003-08-28 22:14 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=796919&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: Windows installer changes for 2.3.1 Initial Comment: Temporary url for the installer is http://starship.python.net/crew/theller/python-2.3.1-beta1.exe Remarks: Only .pyc files, no .pyo are compiled by the installer. This is the default, can be switched off in the "advanced options" installation dialog. In the selecte components dialog, 'Python HTML docs' should be renamed to 'Python HTMLHelp docs'. At the interactive prompt, 'help("BOOLEAN")' prints this: Python 2.3+ (#46, Aug 28 2003, 17:42:54) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> help("BOOLEAN") Sorry, topic and keyword documentation is not available because the Python HTML documentation files could not be found. If you have installed them, please set the environment variable PYTHONDOCS to indicate their location. >>> I only tested Windows XP Pro, admin install (default path, and path containing spaces). On Windows XP Pro, after installing to 'c:\path with spaces', everything seems to work, including IDLE (at least it starts, and finds to chm file). ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-08-28 22:19 Message: Logged In: YES user_id=11105 No need to check anything in, but report bugs and make comments, please. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=796919&group_id=5470 From noreply at sourceforge.net Fri Aug 29 02:55:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 29 04:55:14 2003 Subject: [Patches] [ python-Patches-797157 ] Bug 794658: os.chmod docs, stat constants Message-ID: Patches item #797157, was opened at 2003-08-29 11: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=797157&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: Bug 794658: os.chmod docs, stat constants Initial Comment: See summary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=797157&group_id=5470 From leighamichel6265v at prodigy.net Fri Aug 29 09:16:16 2003 From: leighamichel6265v at prodigy.net (Clayton) Date: Fri Aug 29 05:21:44 2003 Subject: [Patches] patches, Six F*R*E*E VlAGRA tablets, limited time offer Message-ID: <2KSBSVR1TXPx8XVccxX000080c7@2ksbsvr1.staffordoilnh.com> Dear patches@python.org, For the first time on the web, we are offering V*I*A*G*R*A F*R*E*E! Yes, check out this limited time offer: http://pharma-wholesale.24hhosting.com/ This message was sent to address patches@python.org Click here: http://pharma-wholesale.24hhosting.com/remove.php un-subscribe From noreply at sourceforge.net Fri Aug 29 03:55:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 29 05:56:07 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 (Tracker Item Submitted) made by Item Submitter 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: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=797180&group_id=5470 From michael at millenniumshakespeare.com Fri Aug 29 20:46:03 2003 From: michael at millenniumshakespeare.com (Michael) Date: Fri Aug 29 22:46:14 2003 Subject: [Patches] Millennium Shakespeare for Children Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20030829/c8feb599/attachment.htm From michael at millenniumshakespeare.com Sat Aug 30 10:45:44 2003 From: michael at millenniumshakespeare.com (Michael) Date: Sat Aug 30 12:45:56 2003 Subject: [Patches] Millennium Shakespeare for Children Message-ID: <3bjbb85804p104wvhznrqumf7dstn0> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20030830/544ea1f3/attachment.htm From noreply at sourceforge.net Sat Aug 30 11:06:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 30 13:06:19 2003 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 12:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open 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: Walter D?rwald (doerwalter) Date: 2003-08-30 19: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 17: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 15: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 13: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 21: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 11: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 21: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 16: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-18 01: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 23: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 14: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 23: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 21: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 21: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 21: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 21: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 20: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 20: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 18: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 17: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 17: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 14: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 19: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 18:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 17: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 15: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-19 01: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-18 05: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-18 04: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-18 03: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-18 03: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-18 03: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-18 02: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-18 01: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 Sat Aug 30 11:10:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 30 13:10:52 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: Open 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-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 Sat Aug 30 12:27:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 30 14:28:04 2003 Subject: [Patches] [ python-Patches-797868 ] Tutorial, sec. 5.1.4 could contain an extra example Message-ID: Patches item #797868, was opened at 2003-08-30 18:27 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=797868&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michal Pasternak (mpasternak) Assigned to: Nobody/Anonymous (nobody) Summary: Tutorial, sec. 5.1.4 could contain an extra example Initial Comment: Section 5.1.4 of tutorial (List Comprehensions) could contain an extra example. I found it very useful and if it is correct (and compatible with python-programming philosophy) you could include it. Example text follows: """ Another interesting functionality of list comprehensions is, that they can work just like map() for functions with many parameters: some_array = ["param1", "param2", "param3"] a = [foobar("constant", x, 12) for x in some_array] """ Please review it, and if it is correct, you should _definetley_ include this - just because it can be very useful, especially for people, who learn Python. After reading 5.1.4 section I didn't think I can do such things using list comprehensions... good, that those friendly people on #python explained it to me :) Regards, MP ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=797868&group_id=5470 From noreply at sourceforge.net Sat Aug 30 17:04:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 30 19:05:08 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-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 Sat Aug 30 17:25:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 30 19:25:44 2003 Subject: [Patches] [ python-Patches-797868 ] Tutorial, sec. 5.1.4 could contain an extra example Message-ID: Patches item #797868, was opened at 2003-08-30 13:27 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=797868&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michal Pasternak (mpasternak) Assigned to: Nobody/Anonymous (nobody) Summary: Tutorial, sec. 5.1.4 could contain an extra example Initial Comment: Section 5.1.4 of tutorial (List Comprehensions) could contain an extra example. I found it very useful and if it is correct (and compatible with python-programming philosophy) you could include it. Example text follows: """ Another interesting functionality of list comprehensions is, that they can work just like map() for functions with many parameters: some_array = ["param1", "param2", "param3"] a = [foobar("constant", x, 12) for x in some_array] """ Please review it, and if it is correct, you should _definetley_ include this - just because it can be very useful, especially for people, who learn Python. After reading 5.1.4 section I didn't think I can do such things using list comprehensions... good, that those friendly people on #python explained it to me :) Regards, MP ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 18:25 Message: Logged In: YES user_id=80475 Good idea. I've revised the patch example and text. Applied as Doc/tut/tut.tex 1.202 and 1.196.8.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=797868&group_id=5470 From noreply at sourceforge.net Sat Aug 30 17:36:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 30 19:36:28 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-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 Sat Aug 30 17:41:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 30 19:41:15 2003 Subject: [Patches] [ python-Patches-795859 ] typo(PEP 236) Message-ID: Patches item #795859, was opened at 2003-08-27 03:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=795859&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: typo(PEP 236) Initial Comment: In PEP 236, the word ``keep'' is duplicated. for people who keep keep current with the latest release in a timely This should be for people who keep current with the latest release in a timely ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 18:41 Message: Logged In: YES user_id=80475 Applied to version 1.12. Revision should appear on website with 24 hours. Thanks for the report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=795859&group_id=5470 From noreply at sourceforge.net Sat Aug 30 17:52:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 30 19:52:31 2003 Subject: [Patches] [ python-Patches-795947 ] Partial implementation of generator comprehensions Message-ID: Patches item #795947, was opened at 2003-08-27 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=795947&group_id=5470 Category: Parser/Compiler Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Nobody/Anonymous (nobody) Summary: Partial implementation of generator comprehensions Initial Comment: Hello. Recently, Generator Comprehensions were mentioned again on python-list. I have written an implementation for the compiler module. To try it out, however, you must be able to rebuild Python from source, because it also requires a change to Grammar. 1. Edit Python-2.3/Grammar/Grammar and add an alternative to the "listmaker" production: -listmaker: test ( list_for | (',' test)* [','] ) +listmaker: test ( list_for | (',' test)* [','] ) | 'yield' test list_for 1.5. Now [yield None for x in []] parses, but crashes the written-in-C compiler: >>> [yield None for x in []] SystemError: com_node: unexpected node type 2. Apply the patch below to Lib/compiler 3. Use compiler.compile to compile code with generator comprehensions: from compiler import compile import dis code = compile(""" def f(): gg = [yield (x,y) for x in range(10) for y in range(10) if y > x] print gg, type(gg), list(gg) """, "", "exec") exec code dis.dis(f.func_code.co_consts[1]) f() 4. It's possible to write code so that __import__ uses compiler.compile instead of the written-in-C compiler, but I don't have this code handy. Also, a test suite is needed, and presumably a written-in-C implementation as well. (option 2: make the compiler.compile interface the standard compiler, and let the builtin compiler support a Python subset sufficient to bootstrap the written-in-python compiler, or arrange to ship .pyc of the compiler package and completely get rid of the written-in-C compiler) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 18:52 Message: Logged In: YES user_id=80475 Since the pep has been rejected, am closing the patch. But will create a link to it from the PEP (note, the patch stays on the record even after it is closed). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=795947&group_id=5470 From noreply at sourceforge.net Sat Aug 30 23:12:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 31 01:12:37 2003 Subject: [Patches] [ python-Patches-797157 ] Bug 794658: os.chmod docs, stat constants Message-ID: Patches item #797157, was opened at 2003-08-29 03:55 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=797157&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 794658: os.chmod docs, stat constants Initial Comment: See summary. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-31 00:12 Message: Logged In: YES user_id=80475 Applied to Doc/lib/libos.tex 1.128 and 1.127.10.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=797157&group_id=5470 From noreply at sourceforge.net Sat Aug 30 23:12:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 31 01:12:43 2003 Subject: [Patches] [ python-Patches-797157 ] Bug 794658: os.chmod docs, stat constants Message-ID: Patches item #797157, was opened at 2003-08-29 03:55 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=797157&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 794658: os.chmod docs, stat constants Initial Comment: See summary. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-31 00:12 Message: Logged In: YES user_id=80475 Applied to Doc/lib/libos.tex 1.128 and 1.127.10.1. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-31 00:12 Message: Logged In: YES user_id=80475 Applied to Doc/lib/libos.tex 1.128 and 1.127.10.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=797157&group_id=5470 From hueymmasonssba at gte.net Sun Aug 31 12:33:15 2003 From: hueymmasonssba at gte.net (Agralerith) Date: Sun Aug 31 07:41:14 2003 Subject: [Patches] patches, Receive SIX FREE VlAGRA tablets, limited time offer. Message-ID: Dear patches@python.org For the first time on the web, we are offering V*I*A*G*R*A F*R*E*E! Yes, check out this limited time offer: http://pharma-wholesale.24hhosting.com/ http://pharma-wholesale.24hhosting.com/remove.php This message was sent to: patches@python.org From noreply at sourceforge.net Sun Aug 31 08:12:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 31 10:12:50 2003 Subject: [Patches] [ python-Patches-798145 ] nl_langinfo(RADIXCHAR) wrong Message-ID: Patches item #798145, was opened at 2003-08-31 09:12 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=798145&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798145&group_id=5470 From noreply at sourceforge.net Sun Aug 31 08:15:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 31 10:15:49 2003 Subject: [Patches] [ python-Patches-798145 ] nl_langinfo(RADIXCHAR) wrong Message-ID: Patches item #798145, was opened at 2003-08-31 09:12 Message generated for change (Comment added) made by jepler 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: Open Resolution: None 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: Jeff Epler (jepler) Date: 2003-08-31 09: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 Sun Aug 31 08:48:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 31 10:48:18 2003 Subject: [Patches] [ python-Patches-796772 ] CGIHTTPServer fix Message-ID: Patches item #796772, was opened at 2003-08-28 11:34 Message generated for change (Comment added) made by rhettinger 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: Raymond Hettinger (rhettinger) Date: 2003-08-31 09: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 Sun Aug 31 09:13:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 31 11:13:32 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: Open Resolution: None 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-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 Sun Aug 31 10:10:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 31 12:10:54 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 (Settings changed) 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: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=794826&group_id=5470 From noreply at sourceforge.net Sun Aug 31 10:13:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 31 12:14:01 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 (Settings changed) 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: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793559&group_id=5470 From noreply at sourceforge.net Sun Aug 31 10:16:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 31 12:16:42 2003 Subject: [Patches] [ python-Patches-793553 ] urllib SSL authentication docs are wrong Message-ID: Patches item #793553, was opened at 2003-08-23 02:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793553&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib SSL authentication docs are wrong Initial Comment: urllib docs for URLOpener say: Additional keyword parameters, collected in x509, are used for authentication with the https: scheme. The keywords key_file and cert_file are supported; both are needed to actually retrieve a resource at an https: URL. They're not needed, and the certificate is never checked, because _ssl.c doesn't check it (which is documented in the socket.ssl docs). A doc patch is attached. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-08-31 18:16 Message: Logged In: YES user_id=21627 Isn't the purpose of these arguments client-side authentication? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793553&group_id=5470 From noreply at sourceforge.net Sun Aug 31 10:18:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 31 12:18:54 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 loewis 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: 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 Sun Aug 31 10:19:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 31 12:19:28 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 (Settings changed) 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: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793021&group_id=5470 From noreply at sourceforge.net Sun Aug 31 10:20:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 31 12:20:32 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 (Settings changed) 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: Open Resolution: None 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.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=792338&group_id=5470 From noreply at sourceforge.net Sun Aug 31 10:38:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 31 12:38:57 2003 Subject: [Patches] [ python-Patches-791706 ] POP3 over SSL support for poplib Message-ID: Patches item #791706, was opened at 2003-08-20 07:53 Message generated for change (Comment added) made by loewis 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: Martin v. L?wis (loewis) Date: 2003-08-31 18: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 Sun Aug 31 10:39:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 31 12:39:34 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 (Settings changed) 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: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790000&group_id=5470 From noreply at sourceforge.net Sun Aug 31 10:42:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 31 12:42:39 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 (Comment added) 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: 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: 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 Sun Aug 31 10:45:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 31 12:45:38 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 (Settings changed) 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: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788249&group_id=5470 From noreply at sourceforge.net Sun Aug 31 10:55:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 31 12:55:21 2003 Subject: [Patches] [ python-Patches-786237 ] os.path.exists should use os.access when possible Message-ID: Patches item #786237, was opened at 2003-08-10 15:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=786237&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.exists should use os.access when possible Initial Comment: Compared to os.access, os.stat is very slow (probably due constructing to the stat object it returns). Therefore, os.path.exists should use os.access instead, when possible. (posixpath, I guess ntpath too.) (I didn't include a patch for ntpath since I can't test it.) As a bonus, the code is cleaner too. :) examples: > touch file_that_exists > python2.3 timeit.py -s "from os.path import exists" "exists('file_that_exists')" 100000 loops, best of 3: 15.6 usec per loop > python2.3 timeit.py -s "from newposixpath import exists" "exists('file_that_exists')" 100000 loops, best of 3: 6.17 usec per loop > python2.3 timeit.py -s "from os.path import exists" "exists('file_that_does_not_exist')" 10000 loops, best of 3: 48.9 usec per loop > python2.3 timeit.py -s "from newposixpath import exists" "exists('file_that_does_not_exist')" 100000 loops, best of 3: 6.37 usec per loop ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-08-31 18:55 Message: Logged In: YES user_id=21627 This patch is incorrect (rejecting it), see http://mail.python.org/pipermail/python-dev/2002-June/025511.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=786237&group_id=5470 From noreply at sourceforge.net Sun Aug 31 11:27:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 31 13:27:15 2003 Subject: [Patches] [ python-Patches-798202 ] detect redhat9 Tcl/Tk in configure script Message-ID: Patches item #798202, was opened at 2003-08-31 12:27 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=798202&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798202&group_id=5470 From noreply at sourceforge.net Sun Aug 31 11:30:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 31 13:30:30 2003 Subject: [Patches] [ python-Patches-798202 ] detect redhat9 Tcl/Tk in configure script Message-ID: Patches item #798202, was opened at 2003-08-31 12:27 Message generated for change (Settings changed) made by jepler 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: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798202&group_id=5470 From noreply at sourceforge.net Sun Aug 31 12:09:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 31 14:09:16 2003 Subject: [Patches] [ python-Patches-793553 ] urllib SSL authentication docs are wrong Message-ID: Patches item #793553, was opened at 2003-08-23 01:15 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793553&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib SSL authentication docs are wrong Initial Comment: urllib docs for URLOpener say: Additional keyword parameters, collected in x509, are used for authentication with the https: scheme. The keywords key_file and cert_file are supported; both are needed to actually retrieve a resource at an https: URL. They're not needed, and the certificate is never checked, because _ssl.c doesn't check it (which is documented in the socket.ssl docs). A doc patch is attached. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2003-08-31 19:09 Message: Logged In: YES user_id=261020 Ah. That appears to be true. In that case, do you agree that the following is still wrong (taken from urllib.URLOpener docs)? Additional keyword parameters, collected in x509, are used for authentication with the https: scheme. The keywords key_file and cert_file are supported; both are needed to actually retrieve a resource at an https: URL. You don't need either dict entry for opening most https: URLs. Also, it gives no clue that x509 is for client authentication, and that server authentication is not done. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-31 17:16 Message: Logged In: YES user_id=21627 Isn't the purpose of these arguments client-side authentication? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793553&group_id=5470 From noreply at sourceforge.net Sun Aug 31 12:27:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 31 14:27:33 2003 Subject: [Patches] [ python-Patches-793553 ] urllib SSL authentication docs are wrong Message-ID: Patches item #793553, was opened at 2003-08-23 02:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793553&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib SSL authentication docs are wrong Initial Comment: urllib docs for URLOpener say: Additional keyword parameters, collected in x509, are used for authentication with the https: scheme. The keywords key_file and cert_file are supported; both are needed to actually retrieve a resource at an https: URL. They're not needed, and the certificate is never checked, because _ssl.c doesn't check it (which is documented in the socket.ssl docs). A doc patch is attached. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-08-31 20:27 Message: Logged In: YES user_id=21627 Sure, I agree the current documentation is wrong. It would be good to test the feature before correcting the documentation, though. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-08-31 20:09 Message: Logged In: YES user_id=261020 Ah. That appears to be true. In that case, do you agree that the following is still wrong (taken from urllib.URLOpener docs)? Additional keyword parameters, collected in x509, are used for authentication with the https: scheme. The keywords key_file and cert_file are supported; both are needed to actually retrieve a resource at an https: URL. You don't need either dict entry for opening most https: URLs. Also, it gives no clue that x509 is for client authentication, and that server authentication is not done. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-31 18:16 Message: Logged In: YES user_id=21627 Isn't the purpose of these arguments client-side authentication? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793553&group_id=5470 From noreply at sourceforge.net Sun Aug 31 12:28:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 31 14:28:25 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 (Settings changed) 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: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798202&group_id=5470 From noreply at sourceforge.net Sun Aug 31 12:36:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 31 14:37:05 2003 Subject: [Patches] [ python-Patches-798202 ] detect redhat9 Tcl/Tk in configure script Message-ID: Patches item #798202, was opened at 2003-08-31 12:27 Message generated for change (Comment added) made by jepler 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: Open Resolution: None 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: Jeff Epler (jepler) Date: 2003-08-31 13: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 Sun Aug 31 13:47:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 31 15:47:59 2003 Subject: [Patches] [ python-Patches-798244 ] More urllib2 examples Message-ID: Patches item #798244, was opened at 2003-08-31 20: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=798244&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: More urllib2 examples Initial Comment: I'm posting this here because I couldn't see how to upload a file to bug 545480. Here are some more examples. I don't use a proxy, so I haven't tested them. They're very simple though (famous last words...). I include examples about adding headers, since I get the impression people assume it's awkward to do this with urllib2. Also, User-Agent is a special case that often comes up. The patch also fixes a couple of markup nits. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798244&group_id=5470 From noreply at sourceforge.net Sun Aug 31 13:49:43 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 31 15:50:41 2003 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 12:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None >Status: Open 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: Walter D?rwald (doerwalter) Date: 2003-08-31 21:49 Message: Logged In: YES user_id=89016 Thanks! Here's another one: test_slice.py ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-31 01: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 19:10 Message: Logged In: YES user_id=80475 Will do! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-30 19: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 17: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 15: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 13: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 21: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 11: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 21: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 16: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-18 01: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 23: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 14: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 23: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 21: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 21: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 21: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 21: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 20: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 20: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 18: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 17: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 17: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 14: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 19: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 18:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 17: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 15: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-19 01: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-18 05: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-18 04: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-18 03: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-18 03: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-18 03: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-18 02: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-18 01: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 Sun Aug 31 13:49:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 31 15:50:46 2003 Subject: [Patches] [ python-Patches-545480 ] Examples for urllib2 Message-ID: Patches item #545480, was opened at 2002-04-18 05:13 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=545480&group_id=5470 Category: Documentation Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Jeremy Hylton (jhylton) Summary: Examples for urllib2 Initial Comment: An associate who's learning Python recently complained about a lack of examples for urllib2. As a starting point, I'd like to submit the following: This example gets the python.org main page and displays the first 100 bytes of it: >>> import urllib2 >>> url = urllib2.urlopen('http://www.python.org/') >>> print url.read()[:100]